In theory, first, design patterns are expected to be tailored to each particular situation. What you reuse is the abstract solution, not the code itself.
And it is true, whatever the design pattern you may consider, it is just not possible to implement it once and then reuse the code.
When I first thought about this topic I remember I immediatly thought of Observer and Iterator patterns as possible objections since they are both defined as interfaces and classes in the java API itself. Are they counter-examples of what is stated before ?
I don’t think so. I tried to use the Observer/Observables classes built-in in the Java API several times, but every time they were not suited for my needs so I had to define my very own for the needs of my application. This is a good example of how a pattern can be expressed in code, for one particular case, but cannot be really reused accros other cases. The Iterator pattern proves that again, as there is not one but already two interfaces in the Java API for this simple thing. And if you take a look at the commons collections you will find many other variations on this pattern, such as OrderedIterator and ResettableIterator.
So everytime I see a framework trying to freeze patterns in code, which is what a framework does in essence, it becomes obvious that this reduces reusability a lot (to be honest I am now rather defiant about frameworks).
Initially published on Jroller on Thursday May 12, 2005