design patterns criticized on wikipedia
ripped from the wikipedia article on design patterns. I wa s doing some reading trying to stay up to date on cfmx communities buzz words. whatcha think design patterns just another name for bad design?
The concept of design patterns has been criticized by some in the field of computer science.
[edit]
Targets the wrong problem
The need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no "pattern" to label and catalog. Paul Graham writes in the essay Revenge of the Nerds[3].
This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. 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? often that I'm generating by hand the expansions of some macro that I need to write.
Peter Norvig provides a similar argument - he demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan[4].
Further arguments along this line are discussed on Portland Pattern Repository's wiki.[5][6]
[edit]
Lacks formal foundations
The study of design patterns has been excessively ad hoc, and some have argued that the concept sorely needs to be put on a more formal footing. At OOPSLA 1999, the Gang of Four were (with their full cooperation) subjected to a show trial[7], in which they were "charged" with numerous crimes against computer science. They were "convicted" by 2/3 of the "jurors" who attended the trial[8].
[edit]
Leads to inefficient solutions
The idea of a design pattern is an attempt to standardize what are already accepted best practices. In principle this might appear to be beneficial, but in practice it often results in the unnecessary duplication of code. It is almost always a more efficient solution to use a well-factored implementation rather than a "just barely good enough" design pattern.[citation needed]
[edit]
Does not differ significantly from other abstractions
Some authors allege that design patterns don't differ significantly from other forms of abstraction[9], and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years.[10] It is further argued by some that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexandar's pattern language as a form of documentation; a practice which is often ignored in the literature. [citation needed]
[edit]
Targets the wrong problem
The need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no "pattern" to label and catalog. Paul Graham writes in the essay Revenge of the Nerds[3].
This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. 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? often that I'm generating by hand the expansions of some macro that I need to write.
Peter Norvig provides a similar argument - he demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan[4].
Further arguments along this line are discussed on Portland Pattern Repository's wiki.[5][6]
[edit]
Lacks formal foundations
The study of design patterns has been excessively ad hoc, and some have argued that the concept sorely needs to be put on a more formal footing. At OOPSLA 1999, the Gang of Four were (with their full cooperation) subjected to a show trial[7], in which they were "charged" with numerous crimes against computer science. They were "convicted" by 2/3 of the "jurors" who attended the trial[8].
[edit]
Leads to inefficient solutions
The idea of a design pattern is an attempt to standardize what are already accepted best practices. In principle this might appear to be beneficial, but in practice it often results in the unnecessary duplication of code. It is almost always a more efficient solution to use a well-factored implementation rather than a "just barely good enough" design pattern.[citation needed]
[edit]
Does not differ significantly from other abstractions
Some authors allege that design patterns don't differ significantly from other forms of abstraction[9], and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years.[10] It is further argued by some that the primary contribution of the Design Patterns community (and the Gang of Four book) was the use of Alexandar's pattern language as a form of documentation; a practice which is often ignored in the literature. [citation needed]
Whoever made this post cites the Gang of Four book. Maybe they should read the Anti-patterns book. Anti-patterns shows the wrong ways that programmers try to solve problem, and how they can be fixed with 'patterns'.