Meant to send this to the list, sorry.

----------  Forwarded Message  ----------

Subject: Re: [PHP] If design patterns are not supposed to produce reusable 
code then why use them?
Date: Thursday 31 December 2009
From: Larry Garfield <>
To: "Tony Marston" <>

On Wednesday 30 December 2009 10:50:40 am Tony Marston wrote:
> I have recently been engaged in an argument via email with someone who
> criticises my low opinion of design patterns (refer to
> ). He says that
> design patterns are merely a convention and not a reusable component. My
> argument is that something called a pattern is supposed to have a recurring
> theme, some element of reusability, so that all subsequent implementations
> of a pattern should require less effort than the first implementation. If
> design patterns do not provide any reusable code then what is the point of
> using them?
> I do not use design patterns as I consider them to be the wrong level of
> abstraction. I am in the business of designing and developing entire
> applications which comprise of numerous application transactions, so I much
> prefer to use transaction patterns (refer to
> and
> ) as these
> provide large amounts of reusable code and are therefore a significant aid
> to programmer productivity.
> What is your opinion? Are design patterns supposed to provide reusable code
> or not? If not, and each implementation of a pattern takes just as much
>  time as the first, then where are the productivity gains from using design
>  patterns?

It depends what you're reusing.  Design patterns are reusable concepts, not 
reusable code.  That's the key difference.

Knowledge of design patterns is like knowledge of how different food 
ingredients interact.  "Hm, this needs something to bring out the taste more, 
so I'll add salt."  You're not going to add the same salt to each dish, 
obviously, but the idea is that you need something that will bring out the 
taste, and there are certain spices that will bring out the existing taste of 
whatever it is you put them on, such as salt.  

Similarly, if you want, say, a piece of code that will connect to a database, 
you want a pre-built library, not a design pattern.  (There's no shortage of 
those.)  If, however, you want a mechanism by which you can have different 
implementations of the same system, and want to swap them out without 
rewriting the calling code, then what you want is the factory *pattern*.  
There may not be existing code yet for whatever system you're writing.  
However, once you recognize "Ah, I want a common interface with a swappable 
implementation, and I want to pick the implementation at runtime based on some 
arbitrarily complex logic", then you know you don't need to think through how 
you go about structuring the code to do that.  Instead, you look up a 
description of the factory pattern and go "ah, that makes sense, and it solves 
3 problems that I didn't realize I'd run into later".  Then you go and 
implement code that follows that pattern, and you don't have to think through 
the algorithm.

Now, it is possible to make generic implementations of some patterns that you 
can re-leverage.  Eg, you can have a common factory interface and a way to 
request a factory, which in turn will give you the implementation object you 
want.  The common elements of those factories you move up to a parent class, 
and therefore reuse code that way.  This is known as a "Factory factory", and 
is in some cases very useful and in others gross over-engineering.  Knowing 
which is which is something you learn through experience.

--Larry Garfield


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to