Archive for August, 2005

Service Patterns and Anti-Patterns

Microsoft’s John Evdemon has written an interesting article entitled Principles of Service Design: Service Patterns and Anti-Patterns.

In the article, he mentions two anti-patterns, the first being a web service interface that is too fine grained and the second is a too generic interface with no real service contract. He also lists three patterns, which show document-based communications, idempotent messages, and reservations.

Even though the patterns mentioned in the article are not as good as those in Enterprise Integration Patterns, it still is an interesting read.

Comments off

Kitchen Cupboard Anti-pattern

Recently, I have come across an anti-pattern that all of us has seen from time to time. After some discussion with my coworker Uri, I decided to call it the Kitchen Cupboard Anti-pattern.

The pattern takes its name from a situation we’ve all experienced: you want to store something in a jam-packed kitchen cupboard, so you open it up, and your Rice Krispies, peanut-butter, coffee, and marmalade falls out. For a short moment you ponder whether to rearrange the cupboard, so that everything would fit more nicely, but after three seconds you decide to wedge everything in there, and quickly close the door. You silently hope that someone else will open the door next time, and that he (or probably she) will clean the cupboard up.

The Anti-pattern is quite similar: you were told to fix an application you know nothing about, so you decide to browse through the source code. It is even worse than you expected: code was copied from place to place, there are 1000+ classes; all suitable for the Daily WTF, hardly any documentation; the documentation that does exists hasn’t been updated in years, and half of the unit tests fail. You ponder whether to refactor the app, or at least the part you’re supposed to fix. But after three seconds, you decide to wedge your code in there, run the unit tests (for the part of the application you touched anyway), and commit. You silently hope that someone else will be put on the project next, and that she (or probably he) will refactor the project.

Comments (2)