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
