There's a lot of talking around patterns in the last years. What patterns really are?
wikipedia.com says: "In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."
Christopher Alexander says: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"
GoF says: "A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context."
Alexander is the "father" of the idea, but GoF are accredited with the idea to apply patterns to programming. But don't let the GoF patterns mislead you. Those are only instances (Radu Marinescu) of the more general idea of pattern, the one intended by Alexander. The GoF patterns apply only to OOP and especially to static typed languages (C++/C#, Java, etc.). But these patterns don't apply for example to dynamic languages (like Lisp). Peter Norvig pointed this out in his paper "Design Patterns in Dynamic Programming": "16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++.", "16 of 23 patterns are either invisible or simpler." This lead people to say that "Patterns are signs of weakness in programming languages."(Mark Dominus - "Design patterns of 1972") and "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough." (Paul Graham - "Revenge of the Nerds"). I think this is true, every pattern (or almost every) shows a missing feature in the language. Take for example the visitor pattern in C++/Java; it shows the missing of double-dispatch in the language. The same way in C we have the "Object-oriented class pattern" which shows the lack of OOP. So i must agree with Paul Graham that a pattern is a sign that were missing an higher abstraction.
If you want to know more about what Alexander's idea of patterns is then you better read his books, not GoF! Another book that speaks about Alexanders patterns in programming, not instances, is "Patterns of Languages" by Richard P. Gabriel.
So when you think at patterns, don't think at instances, but at a meta-level (Radu Marinescu), at the real idea of pattern.
wikipedia.com says: "In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations."
Christopher Alexander says: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice"
GoF says: "A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context."
Alexander is the "father" of the idea, but GoF are accredited with the idea to apply patterns to programming. But don't let the GoF patterns mislead you. Those are only instances (Radu Marinescu) of the more general idea of pattern, the one intended by Alexander. The GoF patterns apply only to OOP and especially to static typed languages (C++/C#, Java, etc.). But these patterns don't apply for example to dynamic languages (like Lisp). Peter Norvig pointed this out in his paper "Design Patterns in Dynamic Programming": "16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++.", "16 of 23 patterns are either invisible or simpler." This lead people to say that "Patterns are signs of weakness in programming languages."(Mark Dominus - "Design patterns of 1972") and "When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough." (Paul Graham - "Revenge of the Nerds"). I think this is true, every pattern (or almost every) shows a missing feature in the language. Take for example the visitor pattern in C++/Java; it shows the missing of double-dispatch in the language. The same way in C we have the "Object-oriented class pattern" which shows the lack of OOP. So i must agree with Paul Graham that a pattern is a sign that were missing an higher abstraction.
If you want to know more about what Alexander's idea of patterns is then you better read his books, not GoF! Another book that speaks about Alexanders patterns in programming, not instances, is "Patterns of Languages" by Richard P. Gabriel.
So when you think at patterns, don't think at instances, but at a meta-level (Radu Marinescu), at the real idea of pattern.
No comments:
Post a Comment