Re: If design patterns are not supposed to produce reusable code then why use them?

On Wed, Dec 30, 2009 at 04:50:40PM -0000, 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? > There's a weird terminology problem here. A "design pattern" is just an idea. Once you implement it, it can become a source of reusable code. > > > 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 on how you implement it. You can prevent it from being reusable by implementing it in such a way that there's just no way to adapt it to different circumstances. But for the most part, it's like any other code you expect to reuse, whether it's just a function, a plain class or whatever. If you implement it properly, it will be reusable elsewhere. Paul -- Paul M. Foster