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. > > 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. 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. 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. 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. Remember, code is irrelevant. You don't sell code. You sell ideas and concepts, implemented in code. 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. 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
