"Larry Garfield" <larry@xxxxxxxxxxxxxxxx> wrote in message news:201001010553.41956.larry@xxxxxxxxxxxxxxxxxxx > 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. Knowledge of how foods interact will not in itself make anyone a good cook. Knowledge of design patterns will not in itself make anyone a good programmer. It is how that knowledge is applied which makes the difference. The problem with design patterns is that the actual implementation is left up to the indvidual, and if the implementation is faulty the fact that a design pattern was used is nothing more than a red herring. >> > 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. But the problem is that you DO have to think through the algorithm as a design pattern exists just as a vague outline, a description of a possible solution, not a workable solution that you can just plug in and go. >> 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. I may be using constructs which have proved to be efficacious in my many years of experience, but I do not look at my solutions using the vocabulary of design patterns as the vocablary is too wishy-washy, too vague, too much theory and too little substance. > 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 > ignorance. The why is it that my critics always say that "real programmers use design patterns" and that if I don't then I cannot be a "real" programmer? > 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 > stupid. But design patterns do not provide workable solutions, they provide outlines for possible solutions which you then have to build yourself. > Remember, code is irrelevant. You don't sell code. You sell ideas and > concepts, implemented in code. But surely if the implememnation is bad then the concepts are irrelevant. Just because an application has been designed using all the "correct" OO concepts and built using every design pattern ever conceived does not mean that it will be a success. I was actually involved in a system just like that, and I can report that it was a total disaster. It may have been used all the right buzzwords, but it was still crap. > 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. But if you have to spend time researching which pattern (or combination of patterns) sounds like that it may be a match for your current problem, then you have to build the code yourself from scratch, where exactly is the saving? An experienced programmer does not need to know the name of the pattern he is implementing in order to write good code. Just because an inexperienced programmer does know the name of a design pattern does not mean that his implementation will be correct. > 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 I offer an alternative view - there are those programmers who need design patterns to fill a hole in their experience, as a sort of mental crutch, and there are those who do not need design patterns as they have the experience and ability to work without them, just as an experienced cyclist does not need training wheels, and an experienced artist does not need a painting-by-numbers kit. -- Tony Marston http://www.tonymarston.net http://www.radicore.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
