On Friday 01 January 2010 05:26:48 am Tony Marston wrote:

> > 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.
> Food recipes are a bad analogy for design patterns. A food recipe
>  explicitly identifies a list of ingredients and a list of actions which
>  are required to produce the intended result. The design pattern equivalent
>  of a recipe would simply state "take a bunch of ingredients, mix them up,
>  heat them up, serve them up". A design pattern merely identifies the
>  concept, not the
> implementation, so where is the REAL benefit? Where is the re-usability?

Note that I did not say that design patterns are a recipe.  I said they're 
knowledge of how different foods interact.  They're meta-knowledge that makes 
you a better chef, not a faster short-order cook.

> > 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.
> I would not use the factory pattern for such a thing. I have actually
> written an application which can switch between database engines - MySQL,
> PostgreSQL and Oracle - simply by changing a single line of code. Although
>  I *could* use the factory pattern, in my experience it would be overkill
>  and too complicated.

Oh really?  I've written such a DB abstraction system as well.  (I think most 
people have at some point.)  Although I did not specifically go into it saying 
"I will use a factory for this", in practice it really is.  Some client code 
says "hey, I need a DB connection, gimme!", an intermediary piece of code 
figures out which DB connection you need (based on configuration data, what 
servers are available, or whatever), and passes back a PDO connection object 
on which you run queries.  That's a factory, in a nutshell.  I suspect your DB 
abstraction system works on the same general principle.

Yes, you're already using common design patterns, I wager, even if you had to 
"invent" them yourself.

However, by understanding it AS a factory pattern, you can explain how it 
works to someone else through a common vocabulary.  You can also look at your 
implementation and see where it's going to be extensible and where it's not by 
comparing it to similar approaches that have already been tried and vetted.

The savings is in going "oh, hey, this approach to my problem has already been 
tried, and what I was going to do would have broken here, here, and here.  But 
by following this similar approach, I can avoid those problems and spend less 
time rewriting code later".

Yes, I have in fact run into that situation myself on more than one occasion.

> The very idea of a "factory factory" fills me with nausea. I have seen
> several examples and my immediate response has always been "real
>  programmers don't write code like that". Yet too many programmers are
>  taught that they MUST use design patterns, so they follow blindly without
>  any regard for the consequences.
> Tony Marston

"Real programmers" don't make jibes about what "real programmers" do out of 

Yes, always blindly following a given design pattern for the sake of following 
a design pattern is stupid.  Blindly ignoring established "solved problems" 
just for the sake of avoiding those pointless design patterns is just as 

Remember, code is irrelevant.  You don't sell code.  You sell ideas and 
concepts, implemented in code.  By not having to re-invent the ideas and 
concepts every time, you can save a great deal of time and effort, and 
potentially a great deal of code that you don't need to rewrite later from 
going down a dead-end.

There's two kinds of developers: Those that understand how they're using 
design patterns and those that don't understand design patterns. :-)  But both 
are, in practice, using them, even if some are doing so badly (either over- or 
under-using them).

--Larry Garfield

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to