A pattern is simply a device used to skip out on costly dollars (as opposed to cheap dollars). Software development is a low loyalties field. When new workers come in and old ones are laid off, or when the project is complete and you will likely not be working on the project again in the future, design patterns can be useful. Loosely stepping withing the confines of a pattern can be of great benefit (as well as safe a ton of documentation - if you like leaving assumptions - the mortal enemy of the programmer.). There are times when I look over project and can pick out a simple, or sometimes simply anal, programmer. Forcing square pegs into round holes, and round holes into diamond pegs. If you are lost on that, you know the feeling I get when I try to understand why someone would subject their logic solely to the pattern. Like any other system, there needs to be room for well documented deviations. This being said, I am a fan of transactional patterns. A program is like a city. While structure is important, the "transactions" amongst it's denizens are the focus. While the structure may be able to handle all transactions at first, growth will likely force expensive and extensive remodeling. Tepees vs Skyscrapers, I guess. This is probably fragmented, but so is my brain right now. :) On Mon, Jan 4, 2010 at 8:30 AM, Robert Cummings <robert@xxxxxxxxxxxxx>wrote: > Richard Quadling wrote: > >> 2009/12/30 Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx>: >> >>> 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, >>> >> > Design patterns re-use the approach to solving a particular problem set. > Note that I said approach, because the code may not be re-usable, but the > tenets of the solution are embodied by the pattern regardless of the > language used. In this way, design patterns are indeed re-usable. When you > see that a particular problem falls within the domain of a Design Pattern, > then the implementation is straightforward since you can use the design > pattern to guide your implementation. > > > 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? >>> >> > Each subsequent use of a design pattern should indeed require less effort. > As you absorb fully the pattern, it becomes easier and easier to see how > problems fit within one pattern or another or multiple patterns. Having at > that point already implemented solutions using design patterns, it should > become easier each time you create a solution using a previously used design > pattern. > > > 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? >>> >> > If I ask you to classify bugs by genus, does it not become easier and > easier to classify any given bug based on your previous experience of > knowing what constitutes membership in a particular genus? The same is true > of design patterns. > > Cheers, > Rob. > -- > http://www.interjinn.com > Application and Templating Framework for PHP > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >
