"Larry Garfield" <larry@xxxxxxxxxxxxxxxx> wrote in message news:200912311743.16759.larry@xxxxxxxxxxxxxxxxxxx > 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. 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? > 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. > 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. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
