Meant to send this to the list, sorry. ---------- Forwarded Message ---------- Subject: Re: If design patterns are not supposed to produce reusable code then why use them? Date: Thursday 31 December 2009 From: Larry Garfield <larry@xxxxxxxxxxxxxxxx> To: "Tony Marston" <tony@xxxxxxxxxxxxxxxxxxxxxxxx> 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 > http://www.tonymarston.net/php-mysql/design-patterns.html ). 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 > http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and > http://www.tonymarston.net/php-mysql/transaction-patterns.html ) 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 (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
