Talk:Software design pattern/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Criticism section

An anon removed the cricicism section [1] iwith the comment

(Moved valid information out of a criticisms section into the rest of the article. In the process, removed information that was the result of the writer's personal ignorance.)

The remove material is

Criticism

In the field of computer science, there exist some criticisms regarding the concept of design patterns.

Workarounds for missing language features

Users of dynamic programming languages have discussed many design patterns as workarounds for the limitations of languages such as C++ and Java.

For instance, the Visitor pattern need not be implemented in a language that supports multimethods. The purpose of Visitor is to add new operations to existing classes without modifying those classes. In C++, a class is declared as a syntactic structure with a specific and closed set of methods. In a language with multimethods, such as Common Lisp, methods for a class are outside of the class structure, and one may add new methods without modifying it.

Similarly, the Decorator pattern amounts to implementing dynamic delegation, as found in Common Lisp, Objective-C, Self and JavaScript.

Many patterns imply object-orientation or more generally mutable state, and so are meaningless in functional programming style, in which data is immutable or treated as such. For example, the Iterator pattern is a generalisation of 'for' loops, an inherently imperative notion.

Does not differ significantly from other abstractions

Some authors allege that design patterns don't differ significantly from other forms of abstraction, 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 cited as an example of a "pattern" that predates the concept of "design patterns" by several years. 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 Alexander's pattern language as a form of documentation; a practice that is often ignored in the literature.

should any of this be restored?--Salix (talk): 08:09, 4 November 2010 (UTC)

I'd say, go ahead and re-include this section. Perhaps it's not the best sourced right now, but there are pieces of criticism published out there; let's hope more links will be added soon enough. One thing comes to my mind, Paul Graham's

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.

(from http://www.paulgraham.com/icad.html); perhaps the discussion at http://www.c2.com/cgi/wiki?AreDesignPatternsMissingLanguageFeatures is a good start too. Dexen (talk) 16:50, 19 November 2010 (UTC)

As it currently stands the criticism section is based on irgnorance; it criticises the 'concept' of patterns. That is like criticising the 'concept' of solutions or answers to questions or formula. (Software/Design/Architecture) Patterns are solutions documentation in relativity consistent way. Individual patterns may be 'poor' or 'wrong' but that makes them anti-patterns or poor solutions, it doesn't make the concept of patterns wrong, if anything it justifies them further. MartinSpamer (talk) 07:22, 27 November 2011 (UTC)

Your phrasing seems to conform to the criticism that "design patterns" are hardly new. "That is like criticising the 'concept' of solutions or answers to questions or formula.". What /isn't/ a solution or answer? (Software) engineers as I understand them apply knowledge to solve problems. It follows then there have always been "design patterns" as long as there have been (software) engineers, and thus "design patterns" existed long before the Gang of Four. But maybe you mean something more specific than just knowledge. But then again, maybe not. A solution, good or bad, addresses some problem. Documentation records this solution in a form that can be transmitted to someone else. A "relatively consistent way" could in the extreme mean totally consistent, like some kinds of logic, or something totally free-formed, like some kinds of art (and yes, people have been inspired to create and document a solution based on an encounter with art). If these are "(Software/Design/Architecture) Patterns", then I claim first you are correct that "it doesn't make the concept of patterns wrong", for how can a concept be wrong?, and second, that one part of the criticism section is actually valid because the concept /of a concept/ is hardly new (though for a twist, our /concept/ of a concept has changed over time). In other words, the concept of "design pattern" seems to me indistinguishable from "knowledge", and could thus be stated as: knowledge is documentation of solutions in a relativity consistent way, and pretty much state the same thing. It's quite telling that you put all the adjectives to "patterns" in brackets, suggesting you don't mean just software design patterns, but patterns in general.

(GeorgePaci incidentally stated the same thing about another of Christopher Alexander's ideas, that "QWAN" was a replacement for "good" (… '"That design is good" and rewrites them as "That design has QWAN"'). The same thing here, where "design pattern" replaces "pattern" (or "concept")).

So that I'm not accused of something I didn't say, let me be clear that I too support the concept of documenting solutions in a relatively consistent way (and thus am against "inconsistency", meaning something like "undisciplined", or "ignores previous knowledge (re: patterns) without reason"). However, I don't think all this talk of design patterns has really added much, and perhaps nothing at all, compared to what we would have done had we not borrowed from Alexander's ideas. If he was the first architect to document (repeated) solutions, then good for him. If the Gang of Four was the first to document (software) engineers' knowledge, then good for them. Yet, I don't think that could be the case. That's not to say our ways of recording knowledge have never changed – they have. Rather, (design) patterns might better be thought of (and defined as, one step towards a good /concept/) as documentation to solutions in a /more/ consistent way, more consistent than whatever came before. On this view, a "design pattern" really just looks like a form of organized knowledge, as opposed to being scattered across a million brains and databases, much like Wikipedia is a form of organized knowledge compared to the millions of sources that is (supposedly) cites.

The bottom line is that I would drop all this design pattern talk because there already are burgeoning fields that talk about knowledge. For instance, cognitive scientists would talk about "mental representations", and could ask questions that design pattern people could not, like are some mental representations more "difficult" than others, such as, do they take up more processing time? This could then have relevance to software engineering because it could tell us, somewhat, if some "design patterns" give us more trouble than others). In other words, software design patterns (Gang of Four, Alexander's ideas, etc.) to me seem disconnected from the rest of our knowledge. This is a bad thing. If anything it justifies them less.

tl;dr: software design patterns have become indistinguishable from knowledge or concepts, and all talk of it can be done away with, but what it refers to cannot. KaiSeun (talk) 07:25, 16 February 2012 (UTC)

References

Creating a new category

I am concerned with software design patterns for a few month now. One reason is for educational purposes, creating a lecture with Moodle. There are a lot of design patterns, but somehow the ones defined in the Design Patterns book are taught often first. To help those interested in teaching the subject (to themselves, why not?) or who are interested in the history of this subject, I propose to add a category called Category:GoF pattern or something like that so that all 23 patterns are in one category. As the default place, I will add the Design Pattern book article. What is your opinion? Sae1962 (talk) 15:57, 26 July 2012 (UTC)

Generally support. I'd change the name to Category:Gang of Four design patterns though. This category name should be plural, and spelling things out in full is generally clearer to naive readers.

Also note that if you use the leading colon, you can link to categories without needing the <nowiki> markup. Andy Dingley (talk) 16:08, 26 July 2012 (UTC)

Should Multiton be listed?

As noted on the Multiton "talk" page, Multiton seems to be interchangeable with the "Flyweight Pattern" - the code examples are interchangeable. It seems as if it's just an alternate name for the same pattern, put into a different category. — Preceding unsigned comment added by 38.70.1.35 (talk) 04:20, 5 September 2012 (UTC)

See Also section

Design patterns and TRIZ are similar in that they both define solutions to common problems. A see also section might be an interesting side road. — Preceding unsigned comment added by Billegge (talk • contribs) 12:23, 24 October 2012 (UTC)

" types of design patterns" vs "classification"

redundant (but with diffferent types), or just no explanation of the difference? 68.183.23.147 (talk) 23:38, 16 January 2013 (UTC)

No one has fixed it after more than a year. Any reasonable objection to deleting the "types"?

design patterns vs algorithms

If a design pattern is a "a general reusable solution to a commonly occurring problem", then in what way(s) does it differ from an algorithm? This article doesn't do much to explain exactly what a design pattern is. A simple example would be a good start. WilliamSommerwerck (talk) 19:13, 7 September 2011 (UTC)

As a quick answer, I would say that design patterns differ from algorithm in that design patterns solve software engineering problems rather than computer science problems. That is, they are templates for managing complexity that arrives from interaction among software components. There are many ways to implement depth first search, so even though the algorithm may be the same, on implementation may be far preferable from a software-design perspective in terms of software reusability, etc. That's a sketch of an answer, anyway. 20:38, 7 September 2011 (UTC)

Looking up algorithm, it is described as "a finite list of well-defined instructions", I would say that is different enough. Unfortunately, design patterns are an advanced subject and this is partly why explaining them is so difficult. Typically, one or more design patterns may be used in an algorithm solution expressed in a particular computer language. Books are written on the subject.

Like classic Chinese martial arts movies, one needs good kung fu (term), not just basic knowledge of how to move your arms and legs. – rfrankla (talk) 10:42, 21 April 2014 (UTC)

In Design Patterns/Code Complete - WTF

Not that I have anything against these references, but why on earth should the presence or not of a particular pattern in these books matter? There are numerous patterns that were identified before and after these which aren't included. This section reads like religion, not software engineering. — Preceding unsigned comment added by 81.129.62.42 (talk) 01:43, 15 September 2013 (UTC)

Prior to the publication of GOF little was known on the subject. The authors wanted to provide a standard vocabulary for practitioners to communicate their thoughts and ideas. To begin the process they purposely chose "some of the most important design patterns and present them as a catalog." (I'm being informal because this is the talk page). By virtue of the number of copies sold and the acceptance by software engineers of these ideas, these book are the acknowledged references on the subject. – rfrankla (talk) 09:34, 21 April 2014 (UTC)

I agree - whether a pattern is in some book or another is completely irrelevant. It's like listing birds that are found in one particular field guide. — Preceding unsigned comment added by 68.183.37.167 (talk) 14:32, 28 May 2014 (UTC)

References

External links moved to talk

Looks like we've created a WP:LINKFARM. I've moved all the links from the article to the list below. Anyone want to go through this mess and see if anything fits WP:EL well enough to include? --Ronz (talk) 17:41, 13 June 2014 (UTC)

• Full collection of design patterns (Creational, Structural, Behavioural) in C++ by Antonio Gulli
• 101 Design Patterns & Tips for Developers
• Design Patterns Reference at oodesign.com
• Directory of websites that provide pattern catalogs at hillside.net.
• From Patterns to Components An accessible doctoral dissertation by Karine Arnout.
• Jt J2EE Pattern Oriented Framework
• Lean Startup Business Model Pattern Example of design pattern thinking applied to business models
• Messaging Design Pattern Published in the 17th conference on Pattern Languages of Programs (PLoP 2010).
• On Patterns and Pattern Languages by Buschmann, Henney, and Schmidt
• {{dmoz|Computers/Programming/Methodologies/Patterns_and_Anti-Patterns/|Patterns and Anti-Patterns}}
• Patterns for Scripted Applications
• PerfectJPattern Open Source Project Design Patterns library that aims to provide full or partial componentized version of all known Patterns in Java.
• JPattern JPatterns is a collection of annotations for Design Patterns.
• Printable Design Patterns Quick Reference Cards
• Are Design Patterns Missing Language Features? at the Portland Pattern Repository
• History of Patterns at the Portland Pattern Repository
• Show Trial of the Gang of Four at the Portland Pattern Repository
• Category: Pattern at the Portland Pattern Repository
• "Design Patterns in Modern Day Software Factories (WCSF)". XO Software, Ltd.
• "Core J2EE Patterns: Patterns index page". Sun Microsystems, Inc. Retrieved 2012-08-11.
• Design pattern list with examples, problems, solutions and alternative solutions.
• List of design patterns in the Java API
• The Design Patterns Memory

References

External link to w3sdesign.com

The w3sDesign Patterns website contains encyclopedic and accurate material that is relevant to the understanding of the subject. I would like to add a link to it. What do others think about it? Serv49 (talk) 18:16, 23 October 2014 (UTC)

I have added the link. Serv49 (talk) 10:05, 6 November 2014 (UTC)