Editing Software design pattern (section)

==Criticism==

Some suggest that design patterns may be a sign that features are missing in a given programming language ([[Java (programming language)|Java]] or [[C++]] for instance). [[Peter Norvig]] 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 (programming language)|Lisp]] or [[Dylan (programming language)|Dylan]].<ref name="Norvig1998">{{cite conference
 | last = Norvig
 | first = Peter
 | author-link = Peter Norvig
 | title = Design Patterns in Dynamic Languages
 | url = http://www.norvig.com/design-patterns/
 | year = 1998}}</ref> Related observations were made by Hannemann and Kiczales who implemented several of the 23 design patterns using an [[Aspect-oriented programming|aspect-oriented programming language]] (AspectJ) and showed that code-level dependencies were removed from the implementations of 17 of the 23 design patterns and that aspect-oriented programming could simplify the implementations of design patterns.<ref name="Hannemann2002">{{cite conference
 | last1 = Hannemann
 | first1 = Jan
 | last2 = Kiczales
 | first2 = Gregor 
 | book-title = Proceedings of the 17th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications - OOPSLA '02
 | author-link2 = Gregor Kiczales
 | title = Design pattern implementation in Java and AspectJ
 | year = 2002
 | page = 161
 | conference = OOPSLA '02
 | doi = 10.1145/582419.582436
 | isbn = 1581134711
 }}</ref>
See also [[Paul Graham (computer programmer)|Paul Graham's]] essay "Revenge of the Nerds".<ref name="Graham2002">{{cite web
 | last = Graham
 | first = Paul
 | author-link = Paul Graham (computer programmer)
 | title = Revenge of the Nerds
 | url = http://www.paulgraham.com/icad.html
 | year = 2002
 | access-date = 2012-08-11}}
</ref>

Inappropriate use of patterns may unnecessarily increase complexity.<ref name="CodeComplete2">{{cite book
 | last = McConnell
 | first = Steve
 | title = Code Complete: A Practical Handbook of Software Construction, 2nd Edition
 | url = https://archive.org/details/codecomplete0000mcco
 | url-access = registration
 | year = 2004
 | page = [https://archive.org/details/codecomplete0000mcco/page/105 105]| publisher = Pearson Education
 | isbn = 9780735619678
 }}
</ref> [https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition FizzBuzzEnterpriseEdition] offers a humorous example of over-complexity introduced by design patterns.<ref name="Kragbæk2016">{{cite web
 | last = Kragbæk 
 | first =  Mikael
 | title = FizzBuzzEnterpriseEdition
 | url = https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
 | access-date = 2024-11-19}}
</ref>

By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from [[software reuse]] as provided by [[software componentry|components]], researchers have worked to turn patterns into components. Meyer and Arnout were able to provide full or partial componentization of two-thirds of the patterns they attempted.<ref name = "Meyer2006">{{cite journal
 | first1 = Bertrand
 | last1 = Meyer
 | author-link = Bertrand Meyer
 | first2 = Karine | last2 = Arnout
 | title = Componentization: The Visitor Example
 | journal = [[IEEE Computer]]
 | volume = 39
 | issue = 7
 | pages = 23–30
 |date=July 2006
 | url = http://se.ethz.ch/~meyer/publications/computer/visitor.pdf
 | doi = 10.1109/MC.2006.227
| citeseerx = 10.1.1.62.6082
 | s2cid = 15328522
 }}</ref>

In order to achieve flexibility, design patterns may introduce additional levels of [[indirection]], which may complicate the resulting design and decrease [[Runtime (program lifecycle phase)|runtime]] performance.