Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
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 rob...@interjinn.comwrote: Richard Quadling wrote: 2009/12/30 Tony Marston t...@marston-home.demon.co.uk: 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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
2009/12/30 Tony Marston t...@marston-home.demon.co.uk: 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? -- 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 Hello Tony and everyone else (is it too late to say Happy New Year and back to work?). I think there seems to be a bit of a chicken and egg issue with your comments of design patterns. Design patterns are not blue-sky, out-of-the-box, (insert some other marketing-speak here) concepts. They are standardized descriptions of the purpose of code commonly seem. They are not blocks of code to be reused. They are nothing to do with code reuse per se. They are to show you that the there are ways of standardizing your approach to a problem based upon others experience. They are there to act as templates for how you should be thinking. Do they make you a better programmer? That depends. Do you have to play with others? Is it easier to say we use the MVC, Active Record, Registry and Factory Patterns? If the other members of your team do NOT know these terms, then it is easy enough to read about them and learn what they are for and then see how they've been implemented. They give a common base. Consider the alternative. I used to work on ICL System 25 running dmfx with a 4GL style language which was converted to C before compilation (and for the life of me I can't remember its name - it was over 20 years ago!). The code I had to maintain was written by developers who used to write in assembler macros. That whole argument about goto in modern languages ... well, let's just say that THAT argument certainly didn't exist for them. The name that I heard for this style of coding was called ladder logic. No structure or common style that a newbie like me could see. New programs were bastardised from old programs. Not cleanly, just cobbled and a few goto's thrown in to bypass the unrequired bits. Why? Cause only the original programmer knew what was going on and they'd died a decade ago. Literally! Jump forward through procedural and OOP and maybe AOP. We all learn from the previous generation (standing on the shoulders of giants). So. If they'd used design patterns back when I started out, I'd've been able to understand the code better and faster. I'd probably take just as long to write it, but I'd've been able to describe it clearer and easier. Design patterns are tools to help solve a problem. The solution MAY involve some coding. If you follow a design pattern, then others will be able to follow your code. Design patterns are for community development. And probably for the non-developer interviewers who want to see if the dweeb sat in front of them knows his (reading from script) Active Record from his (reading from script again) Active Record (No, sorry, just said that, ...) MVC (wasn't that a chain of music shops in the UK?)... Having said that, a real programmer only knows not to use Pascal! Pretty much everything else is up for grabs. Regards, Richard. P.S. I know nothing. -- - Richard Quadling Standing on the shoulders of some very clever giants! EE : http://www.experts-exchange.com/M_248814.html Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 ZOPA : http://uk.zopa.com/member/RQuadling -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
Richard Quadling wrote: 2009/12/30 Tony Marston t...@marston-home.demon.co.uk: 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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
Larry Garfield la...@garfieldtech.com wrote in message news:201001010553.41956.la...@garfieldtech.com... 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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
At 5:16 PM + 1/3/10, Tony Marston wrote: 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 Tony: I respect your opinion, but there may be more to this than what you said. As some of you know, I've been pounding code since 1965 and while I'm not the sharpest crayon in the box, I am seeing new things all the time. Perhaps I'm seeing the same thing over and over, but while some of this is rehashing old ideas and presenting them in new packaging, some of it is actually new concepts worth investigating. Clearly OOP is different than procedural code. Likewise, Design Patterns (DP) are different ways to categorize problem solving than relying upon personal experience. These two new camps (OOP/DP) are similar in grouping as are the older procedural and experience camps, if you get my meaning. These different camps are much like a light switch, either you swing one way or the other, but not usually both. I find myself in both camps and being somewhat overwhelmed by the newer camp. The procedural/experience camp provides me with all the tools I need to get anything done that I want done. Whereas, the OOP/DP provides me with enough intrigue to prompt me to investigate -- and the more I look, the better I like. There appears to be more here than just an inexperience issue. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
I think it also to some extent comes down to having a shared vocabulary. Pretty much the same way that you know which technique I'm talking about when I use the word recursion, which algorithm I'm talking about when I say quick sort and which data structure I mean when I say linked list. It's way easier saying quick sort than describing how the algorithms works each time. Yes, you may be able to come up with a sorting algorithm yourself, but now when I tell you that there is a sorting algorithm called quick sort you'll either know which particular sorting algorithm I'm talking about, or you can go look it up. Various implementations may for instance then employ different sorts of optimizations to make it work well in one particular scenario. Design patterns are called patterns specifically because they are things that happen to occur frequently in code, i.e. they are recognizable patterns. It makes sense giving names to such things, and they exist whether or not you name them of course. There are a couple of reasons why a design pattern needn't necessarily yield reusable *code*: 1) They transcend programming languages. A pattern may be implemented in PHP, Python, Java, C++ or some other language, but particularly how you would do it depends on which features and language constructs that are available in the particular language. 2) A particular pattern may be applied to different problems. How you would apply it depends on the nature of the problem. If we just use the strategy pattern as an example, you may have different strategies for an AI in a computer game, you may have different payment strategies in an online shop and you may have different strategies for calculating employees' salary. All of these three things are very different in nature, but they may still use the same an overall shared pattern that is then called a strategy. Tony, I disagree with your notion about design patterns being mental crutches. Besides for educational purposes, I see no reason why you would want to spend time on rediscovering something that someone else already discovered a long time ago. The point is of course not that each time you need to do something you'll scour books and various forms of online resources for a design pattern that fits exactly your needs. The point is that by knowing these patterns, you'll know that for a particular problem this particular solution tends to work well. Indeed as you become more experienced, this will become more transparent and automated so to speak. You may very well discover or come up with some sort of pattern yourself (though you might not necessarily give it a name), and you may even unknowingly do something often that other people call a design pattern and have given a name. Again, this is exactly the reason why we call them patterns: they are things that people tend to come up with, and they tend to work pretty well. Now because there exists a sort of standard nomenclature, when someone asks me how they should approach a particular problem I can tell them to look up a particular pattern instead of trying to (re)explain it when someone else has already done that in great detail. I'm sure you can appreciate the benefit of having a shared vocabulary. It's something that's going on in not just programming, but practically in every field that exists. I hope this makes some sense. It's my take on this anyway. -- Daniel Egeberg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
Larry Garfield la...@garfieldtech.com wrote in message news:200912311743.16759.la...@garfieldtech.com... Meant to send this to the list, sorry. -- Forwarded Message -- Subject: Re: [PHP] If design patterns are not supposed to produce reusable code then why use them? Date: Thursday 31 December 2009 From: Larry Garfield la...@garfieldtech.com To: Tony Marston t...@marston-home.demon.co.uk 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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
Meant to send this to the list, sorry. -- Forwarded Message -- Subject: Re: [PHP] If design patterns are not supposed to produce reusable code then why use them? Date: Thursday 31 December 2009 From: Larry Garfield la...@garfieldtech.com To: Tony Marston t...@marston-home.demon.co.uk 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. 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. 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. --Larry Garfield --- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] If design patterns are not supposed to produce reusable code then why use them?
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? -- 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
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
On Wed, 2009-12-30 at 16:50 +, 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? -- Tony Marston http://www.tonymarston.net http://www.radicore.org In my opinion, patterns primarily aid development of systems where more than one person will be working on it, or where more people may need to refer to the code in the future as a basis for something else. Programming essentially is about not reinventing the wheel all the time, by reusing ideas either as they stand, or as a base for improving upon. To an extent, I think every programmer uses design patterns, it's just a matter of how complex a pattern one uses, and how closely one stays to the original pattern. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
At 4:50 PM + 12/30/09, Tony Marston wrote: 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? -- Tony Marston Tony: I don't think reusable code is the main point of Design Patterns. From what I've read, Design Patterns are more of a If you are faced with this problem, here's a solution kind of thing. Reusable code is more a by-product of the process. Instead Design Patterns are more about identifying and classifying common problems than reusable code. The point is if you can define your problem as a category referenced by Design Patterns, then you are closer to solving it. With that said, I find Design Patterns frustrating because of the level of abstraction most authors use to identify the problem/solution pair. Instead of showing a real world example, their solution are so broad, so encompassing, so abstract, that they lose me. However, I must admit that the newer ways of doing things are bringing to the table ways to do things that were not possible before. So, in the end we all have to keep learning just to keep up. As I've said many times before I've learned something new every day of my life -- and I'm getting damned tried of it. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] If design patterns are not supposed to produce reusable code then why use them?
On Wed, Dec 30, 2009 at 04:50:40PM -, 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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
