Talk:Software design pattern/Archive 1

unsectioned

I added a little bit about the relations between design patterns, and general systems theory, although I think more could be said. For those who don't know, the basic idea of systems theory is to abstract everything into relations between units of the systems. You then, don't need to consider the units, but you can just consider the relations between units. As far as I understand, design patterns would basically are kind of a taxonomy of systems. If you added something about this to article, it might help clarify some details.

--Cronian 03:43, 29 Apr 2005 (UTC)

"Design patterns represent the accumulated knowledge of the community of software developers of standardised solutions to recurring problems."

I found this misleading. The "design" in design patterns usually refers to "object-oriented design", and this definition does not distinguish between OO design issues, algorithms, etc.

I thought the original article was very poorly organized, and included lots of irrelevant linking; I couldn't find a good way to organize what was there, so I rewrote it. (Maybe I'm not a great editor). I also removed some topics (such as social issues) from the bottom which might be "patterns", but are not "design patterns" and certainly not "computer science design patterns". It will be important to scope this article well, if it needs to exist.

Also, some mention needs to be made that the first wiki at c2.com/cgi/wiki was originally constructed to discuss design patterns!

I'm not sure a list of design patterns is needed here, in an encyclopedia, since c2's is likely to remain much better.

-- Kevin Saff

I think an importation question is: Is the use of design patterns limited to object-oriented programming? Some say yes and some, including me, say no. I know the GoF is about design patterns in OOP but there are patterns that are not needed limited to OOP. For example, some may be found in functional programming.

Finally, you can't say we don't need a list of patterns because c2 has one. This is an encyclopedia and most of contents here are after all duplication. Because contents at c2 are not open-content so I don't think it is no problem to cover design patterns as much as c2 does. Of course, it is necessary to clarify a scope. Design patterns in cs should not be confused in patterns in the hacker community. But it is wrong not to have mentions at all as they do exist. -- Taku 00:28, Aug 1, 2004 (UTC)

---

From Taku's user talk page

From a (grateful)reader's perspective

I have a hazy notion of design patterns and was reading this article to get a firmer grip. The following passage is from section "Critique":

Some feel that 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

The word factoring is given as a Wiki reference there and links to mathematical factoring. I dont know what factoring means in this context, but if it rated a link I'm sure it ain't mathematical factoring.

Second I dont know what referenced means here either. Could someone include maybe a terse one-liner about what that means? AXN June 21 4:00pm GMT

Good point. I changed the links. Factoring now points to refactoring and reference to reference. Does that help? —BenFrantzDale 02:42, Jun 22, 2005 (UTC)

Bit confused as to whether design patterns are purely for object-orientation, someone might want to add something about that in there.

Article name

As this article discusses the application of design patterns of architecture in computer science, instead of another meaning of the term, I propose this page should be renamed from Design pattern (computer science) to Design patterns in programming or so? For example, see Logic in computer science, Monads in functional programming and Polymorphism in object-oriented programming. --TuukkaH 06:15, 10 January 2006 (UTC)

To me, it seems appropriate to classify this article differently from Logic in computer science. The word "Logic", even when used in the context of computer science, is a broad concept, or a series of topics, instead of a specific topic. The term "design pattern" in the context of computer science, however, evokes a specific topic, i.e. the "design pattern" as originally presented by the Gang of Four (software). Thus, to me, "Design pattern (computer science)" fits the pattern of field-specific topic names as used throughout the rest of Wikipedia. I would even suggest that entries Monads in functional programming and Polymorphism in object-oriented programming be renamed to "Monads (computer science) and "Polymorphism (computer science)" to keep consistency with the rest of the field-specific topics in Wikipedia. The Rod 17:09, 10 January 2006 (UTC)

Year of publication of Design Patterns

The article states (correctly) that the Design Patterns book was published in 1994, but in the reference section the copyright year is given (again correctly!) as 1995. This is not an error, the book was published in 1994, see [1] and [2], yet the copyright year is given as 1995, both on the books inside cover and on Addison-Wesley's website [3]. I don't know why the years are different. —PrologFan {Talk} 23:20, 12 January 2006 (UTC)

Relational vs OO piece relevant?

Someone offered a critique of design patterns from a relational perspective. How relevant is this, anyway--while design patterns are commonly associated with OO, there's nothing I'm aware of that precludes the use of design patterns with relational databases--regardless of the paradigm of the code.

Regarding the insufficient abstraction piece--a better argument--I'll add some relevant quotes and cites.--EngineerScotty 06:16, 20 January 2006 (UTC)

---

I went and deleted the section in question; here's the text:

It is also said that design patterns encourage navigational database-like structures instead of the allegedly cleaner relational approach where such structures are viewpoints instead of hard-wired into programming code. However, critics of the relational approach suggest that it does not integrate well enough with behavior. The level of coupling that should be supplied between behavior and data is a contentious topic.

As well as the following comment (which is inappropriate to include in the article):

Design patterns and relational databases discussed without treatment of the object-relational impedance mismatch? Whatever a navigational database is, the argument can't ever end up with a comparison of relational theory with object-oriented programming. I would think that the above statement should be made with some references since it's relevance is highly questionable. Aren't the more serious concerns focused on topics such as anemic domain object models [4] and object-relational mapping? [5]

The original author (I'm certain who it is--it's an anonymous IP and per Wikipedia policy, I shall not utter his name here) was asked about the above comment (in another forum) and did not respond, so I'm going ahead and deleting what I consider to be a rather specious argument. Design patterns, after all, are orthogonal to the OO/relational question (and to Table-Oriented Programming for that matter). --EngineerScotty 20:11, 5 February 2006 (UTC)

What's with the disambiguation link to Architectural patterns?

Architectural patterns goes to a disambiguation link. Was this originally linked to a page that was over-written, is it neccessary at all since it ends up being little more than a self-reference, or what?--BigCow 20:18, 4 April 2006 (UTC)

When you follow a redirected link like that, on the top of the page below the title, there's a link you can further follow to get to the redirection page. There you can see the history and that merge to Design patterns was first proposed, and later someone redirected the page to Design pattern. Unfortunately this kind of things happen in the peripheria of Wikipedia. Fortunately this can be reverted.

I see another problem here too: The term architectural pattern isn't necessarily related to design patterns at all. While there are different kinds of design patterns (as this article lists) some of which can be perhaps called architectural, I think Wikipedia should call them architectural design patterns. Architectural patterns that were linked were not design patterns at all but an independent concept in software architecture. In the same way, the other article titles linked in the classification section are in my opinion misleading. I wonder why we haven't had a list of architectural design patterns this far.

The original book Design Patterns used these names internally, or actually just three of them: creational patterns, structural patterns, behavioral patterns. Where do the rest come from? --TuukkaH 21:46, 4 April 2006 (UTC)

Design Patterns and Frameworks

I just stumbled across . I was going to suggest a merge of content into here and Framework, but it's not obvious to me that there's any useful content in Design Patterns and Frameworks (not to mention a total lack of references). Anyone else see anything of value there? Or should the article just be AfDed? --Allan McInnes (talk) 19:10, 26 April 2006 (UTC)

Recent addition to the history section

An anon user recently added the following to the history section:

This book provides both the concept of architectural patterns and a proposed collection of patterns. While the utility of the first concept is not disputed (and in fact was used previously under other names), the utility or convenience of most of the proposed patterns has been critizised for several authors [6][7]

This appears to me to be more related to the DP book, and should probably be moved to Design Patterns. Furthermore, the two references given are to blogs. Both of which are specific critiques of the singleton pattern, rather than critiques of "most of the proposed patterns". So, two questions:

1. Can anyone provide a references to back up the assertion that "most of the proposed patterns has been critizised(sic)"? If not, I'm tempted to simply remove this material as unverified.
2. Assuming that references are forthcoming, does anyone (such as our anon friend who added the content in the first place) object to moving the content in question over to Design Patterns?

--Allan McInnes (talk) 18:57, 4 May 2006 (UTC)

In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year. In the following years, Beck, Cunningham and others followed up on this work.

-- I've removed the above uncited claim, Gamma et.al. are widely credited with applying design patterns to Software Engineering and the ACM proceedings for OOPSLA '87 make no mention of this claim

OOPSLA '87 proceedings

--User:MartinSpamer

I just took a look at the "Panel on Design Methodology" report. It contains a section describing Ward Cunnignham's contributions to the panel, in which we find things such as

Ward cautioned against requiring too much programming at, what he termed, "the high level of wizards." He pointed out that a written "pattern language" can significantly improve the selection and application of abstractions. He proposed a "radical shift in the burden of design and implementation" basing the new methodology on an adaptation of Christopher Alexander's work in pattern languages and that programming-oriented pattern languages developed at Tektronix has significantly aided their software development efforts.

The text of Cunningham and Beck's contribution appears to be available here. There is also reference (in both the panel report, and in Cunningham and Beck's paper, to a 1987 Textronix Technical Report (also by Cunningham and Beck) that also lays out some of these ideas. But unfortunately it doesn't appear to be available online.

Anyway, given all of that, I will reinsert the disuputed text — this time with appropriate citation.

--Allan McInnes (talk) 16:39, 26 May 2006 (UTC)

Criticism section problems

The Criticism section appears to be pretty much a regurgitation (if not actual plagiarism) of http://www.answers.com/topic/design-pattern-computer-science from answers.com. I didn't find the answers.com criticisms particularly convincing and I think we can do better here.

The main criticism I know of tends to be that using a lot of patterns does not guarantee a good design, and in fact, striving for using lots of patterns "just because" can lead to stupid and unaffordable inefficiencies. This tends to be a problem that pertains mainly to young, student or inexperienced programmers. This criticism can be tempered by the fact that sensible, valuable implementations have been made of each and every of the major, proposed design pattern. It's a matter of needing experience in programming them; knowing their theory is one thing, but applying them correctly--and ONLY when needed, with some restraint--is very important.

I did teach software engineering to masters students at Upenn recently, and I found they exhibited an almost awed reverence for design patterns, which in and of itself is not bad, but what they lacked was an understanding of performance and design complexity issues that would temper their judgement on whether to apply a given pattern or not. They needed to be nudged in the direction of KISS (keep it simple and straightforward) with the goal of maintainability tempering the desire for an utterly elegant "OO" design.

Anyway, I think the criticism section should be gutted and rewritten. Does someone have time?Harborsparrow 17:49, 27 October 2006 (UTC)

It's no surprise that the WP article is very similar to the answers.com one. A footnote at the bottom of the answers.com article notes that This entry is from Wikipedia, the leading user-contributed encyclopedia. --Allan McInnes (talk) 23:36, 28 October 2006 (UTC)

Keep in mind, that we should not be inventing new grounds to criticize design patterns--tis original research. If you can find the above argument in the literature, feel free to add it! But stuff that you thought of yourself, no matter how interesting or useful, simply does not belong in the article. (OK to have it here on the talk page). --EngineerScotty 17:43, 11 January 2007 (UTC)

Sorry, cannot help it.... Dpser 22:52, 21 January 2007 (UTC)

Not sure what you can't help (except maybe being amused at how much Wikipedia plaugiarizes from answers.com), Dpser, but I agree fully with Mr. Scott. I think design patterns are very useful, however the culture of reverance built up around them may have detrimental effects. If anyone can find references for this, it'd be great to include in the article. I personally think DPs are phenomenal tools (mostly for communication), but it'd be great to be more "fair and balanced" - JustinWick 18:55, 22 January 2007 (UTC)

couldn't help not posting my opinion ;-) Though it was in 'talk', I chose to remove it and put it in my blog instead. However, design patterns are very useful, as most tools are, when in the appropriate hands. Otherwise they tend to mess up things and become instruments of destruction unless they are used wisely and moderately. It would be great if someone could have some references that make the criticism section better. However, I'm afraid we are trying to turn a craft into science, practical experience is also useful even if there aren't any references... BTW, it was a really nice catch, but I think a plagiarism would only be in the case they did not reference the sources, wouldn't it? Dpser 23:21, 22 January 2007 (UTC)

The problem I find with the criticism section "Targets the wrong problem" is that it seems to be just plain incorrect, rather than a matter of opinion. Given that Design Patterns are extensively used in languages which provide for a high level of abstraction, it really does not make sense. The quote shows a fundemental misunderstanding - Design patterns is about patterns between applications, NOT patterns within code. Criticisms that are factually incorrect, surely should not stand? —The preceding unsigned comment was added by 196.3.50.254 (talk) 14:45, 14 February 2007 (UTC).

You make a good point about patterns being "between applications", or perhaps "across systems". The article doesn't address that, and leaves the reader with the impression that one should implement a particular pattern over and over within a system. That is, of course, at the heart of both Norvig's and Graham's comments — that re-implementation is "bad". OO advocates would never consider re-implementation within a system, they'd just abstract it out and use it by reference. That also addresses the re-use comment. RossPatterson 01:35, 12 March 2007 (UTC)

I've checked the source article of this comment, and I think it really isn't relevant. The author isn't eve.n talking about Design Patters. On that basis, I'll delete this criticism.Matthewdjb 18:13, 14 February 2007 (UTC)

I'm confused about what is happening with the "Targets the wrong problem" section. It irks me that a couple of Lisp zealots can get away with "criticism" that isn't really criticism --- it's just sour grapes. I'm referring to Norvig and Graham; I do respect them, but Lisp has a strange ability to inspire a certain arrogance. I mean, "X out of Y problems can be eliminated by using Lisp" isn't criticism of design patters; it is advocacy for Lisp! This has no place in an article on design patterns. This section should never have been included in the first place and it is high time for it to go.Mistercupcake 00:54, 12 March 2007 (UTC)

Norvig's point is more than sour grapes. His claim is that macro-programming eliminates the need for design patterns, and he's at least partially correct. But macros aren't just a Lisp thing, they're a fundamental concept of programming that most languages have, in some cases for 50 years. Even comparatively modern languages have them, masquerading under names like "generics" and "templates". RossPatterson 01:41, 12 March 2007 (UTC)

Ok, I seem to have stumbled upon one of those situations where Wikipedia has misrepresented the intention of the person it cites. Norvig's and Graham's arguments are completely different. Graham is doing what he does, which he does very well: making a string of controversial claims to stir up the pot. Quite frankly his quote is nothing more than vague speculation... it is straight out of metaphysics. Graham is very far away indeed from the people who actually have to decide which language to use and whether to use a pattern or a macro. The quote is vague, Graham appears to misunderstand the concept of a design pattern, and he claims that the use of design patterns is "institutionalized" which is not only false but a complete distortion of reality: support for patterns comes from practitioners and real programmers, not from standards committees or institutions. They like patterns because it eases communication of architectural terms. Usually the term "troll" has a very negative connotation, but there is nothing wrong with making controversial arguments for the sake of making them. Graham's quote is trollish, and it does not belong in Wikipedia. It belongs where it came from --- in his essay!

Norvig, on the other hand, actually has a wonderful slide show on design patterns which is very illuminating. He says: "16 of 23 patterns have qualitatively simpler implementation in Lisp or Dylan than in C++ for at least some uses of each pattern." He isn't criticizing the concept of a design pattern at all. He should be quoted. The current sentence badly misrepresents his view.Mistercupcake 07:41, 13 March 2007 (UTC)

I've made some edits to the History section and Criticism section and added a new section, all to resolve issues that have been raised previously, except for the formalization criticism. Googling for "design pattern formalization" turns up many sources, including one which purports to catalog a whole family of techniques for the formalization of design patterns [8]... so it is totally inaccurate to say that in March 2007 design patterns have not been formalized.

I'm not terribly happy with the new section. It is a bit scrawny and I don't think it really hits the nail on the head, but I also don't see any evidence that Norvig is actually criticizing the idea of design patterns, so his relevant quote does not strike me as belonging squarely in the criticism section. Any ideas? Mistercupcake 09:12, 15 March 2007 (UTC)

Nice work. Yeah, it's a little scrawny, but it's a good starting point. RossPatterson 12:12, 15 March 2007 (UTC)

Observing my environment I see many young, student, inexperienced or pompous programmers using and loving Design Patterns. I've never seen an end user saying: "Well, I need a Visitor here", while the same user could have been saying to Christopher Alexander: "I need a place to wait in this part of the building". I believe that DPs are the perfect symptom of the software crisis, and for this reason they are so pervasive. Enriirne (talk) 11:35, 12 December 2008 (UTC)

Question

Why pattern names look so stupid? And why they are so misleading? 200.175.229.69 23:46, 2 February 2007 (UTC)

Why your sentence no verb? Maybe someone should delete this inflammatory "question"? - JustinWick 22:40, 4 February 2007 (UTC)

Because you understand only one language, Justin. While 200.175.229.69 was helping you to circumvent your limit, he forgot some verb. It seems that living in a country that, by coincidence, speaks the current common language is not helping you to improve your humbleness. By the way, I agree with 200.175.229.69: DPs' names are pompous Enriirne (talk) 11:48, 12 December 2008 (UTC)

c2.com references

I'm proposing removing these references and the associated text. The references (wiki entries) do not meet WP:SOURCE criteria. Portland Pattern Repository is overlinked as it is. The show trial discussion is unencyclopedic. --Ronz 17:20, 11 March 2007 (UTC)

Concur on the C2 wiki entries. However, please make sure that you don't accidentally also remove the C2 link to Beck and Cunningham's OOPSLA87 paper on patterns - it's not a wiki entry, but rather the only openly accessible online version of that conference paper that I could find. --Allan McInnes (talk) 18:07, 11 March 2007 (UTC)

I don't think this is a problem. There are only 6 c2.com items, all but one in the grouped reference section at the top of the page:

1. <ref name="Beck1987"> — the OOPSLA87 paper that Allan McInnes mentions. This is not a part of the PPR wiki, and indeed hard to find elsewhere online — in fact, this is the reference commonly used for this paper. This should probably be cited with {{cite conference}} instead of {{cite web}}, as it was part of OOPSLA87.
2. <ref name="C2a"> — the PPR wiki's Are Design Patterns Missing Language Features? entry. It's an interesting case of self-criticism by the founding pattern community.
3. <ref name="C2b"> — a discussion of Peter Norvig's Design Patterns in Dynamic Programming, and probably better cited as the original from Norvig's site: http://norvig.com/design-patterns.
4. <ref name="C2c"> — the PPR wiki's Show Trial of the Gang of Four entry. While conducted with tongue firmly placed in cheek, it did serve to focus discussion on how patterns might be a bad idea.
5. <ref name="C2d"> — the PPR wiki's Show Trial Verdict entry. I agree, it's not encylopedic regardless of whether the trial itself was, and ought to be deleted.

The last is the PPR citation in the See also section, which isn't really a reference despite its use of {{cite web}}.

I see no good reason to remove the other 4 (i.e., all but C2d and a kept-but-retargeted C2b). The fact that they're at the PPR shouldn't count too heavily against them. The PPR wiki certainly seems appropriate under the guidelines of Using questionable or self-published sources.

As an aside, the grouped references at the top of the article unfortunately cause false usages when displayed in the References section. Since all of them are actually only used once, they should be moved in-line with the text to get rid of the problem. RossPatterson 19:28, 11 March 2007 (UTC)

I'm not sure I see how the PPR wiki refs are acceptable under Using questionable or self-published sources - the article is not about the patterns community, or the PPR in particular, but about the concept of design patterns.

I do agree that the Norvig stuff is worth keeping, given a direct reference.

--Allan McInnes (talk) 21:33, 11 March 2007 (UTC)

Well, I'd say exception #2 covers the specific references from PPR that we're talking about (although certainly not all possible ones):

2. Professional self-published sources

When a well-known, professional researcher writing within his or her field of expertise has produced self-published material, these may be acceptable as sources, so long as his or her work has been previously published by reliable, third-party publications. ...

I may be being too generous towards PPR, but Cunningham himself obviously meets the criterion. RossPatterson 22:04, 11 March 2007 (UTC)

Ok, I've moved the text over to inline refs, and converted the {{cite web}} to a {{cite conference}} for the Beck/Cunningham paper. Refs C2a and C2b are, I think, subsumed by the direct Norvig reference (which was already in there), so I've removed them. The link to Are Design Patterns Missing Language Features? might make good "Further reading", but I don't think it belongs in the article as a reference. That leaves only the show-trial links, which I haven't removed yet. Again, I think that the "Show Trial" link might be ok as "Further reading", but doesn't belong in the article as a reference (it might make a decent reference for a Wikipedia article on the Show Trial itself, but that's another story). --Allan McInnes (talk) 21:52, 11 March 2007 (UTC)

I can live with all that. RossPatterson 22:06, 11 March 2007 (UTC)

Sorry about the deletion. I actually clarified that I was referring to the wiki links only, but somehow the edit was changed to a deletion. --Ronz 02:41, 12 March 2007 (UTC)

Refs for "Does not differ significantly from other abstractions" section

Several times now, someone has inserted a citation to this article to support the assertion that "Some authors allege that design patterns don't differ significantly from other forms of abstraction". I have read through the cited article, and haven't been able to find anywhere in which any of the authors claim that patterns don't differ from other forms of abstraction. Can someone (User:Skraedingie perhaps, since you were the most recent one to add this ref) point out where in the article there is anything relevant to the sentence the article is being used to provide a citation for? If not, then I don't see the point of including that particular reference.

So we have a source for the opposite position at [[9]] where it is stated:

One of the quotes that I find particularly appealing when I think about the need for patterns that that part of interest in patterns came from "...observations that projects fail despite the latest technology for lack of ordinary solutions"[PLoPD 1]. Patterns provide a way to organize and name those ordinary solutions to make it easier for people to use them.

Here you have Martin Fowler saying that design patterns are WAY different from any other form of (general) abstraction because they consist of "prefab (computer science) data abstractions." It is difficult to talk about this because "abstraction" is overloaded: it has the conventional sense of "removing irrelevant detail" as well as the computer science sense of "providing an information-hiding API". This is a bit crude but it is good enough to make the point that "abstraction" can mean two different things. But not only are design patterns different --- they are important in controlling the complexity of programs written in Algol-like languages. (There is a reference for this precise claim in the GOF show trial page). Design patterns enable the high-level communication of architectural ideas in a consistent language. There simply was no such thing before design patterns. Mistercupcake 06:37, 21 March 2007 (UTC)

The same thing goes for the citation to this article (Google cache used since the link seems to be broken right now), which is provided as a citation for "The Model-View-Controller paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years". The cited article talks about MVC as a pattern, but it in no way "touts" MVC as a pattern that predates the concept of patterns, nor uses the pre-existence of MVC as a criticism of patterns. Am I missing something here? Why does this reference keep getting re-inserted?

--Allan McInnes (talk) 18:42, 18 March 2007 (UTC)

confusion pattern

I found the page titled confusion pattern by clicking on "what links here" on another page. But confusion pattern is a complete orphan: nothing else at all links to it. Perhaps those reading this page should know what should link to it---maybe at least some list of design patterns or something. Michael Hardy 19:49, 17 May 2007 (UTC)

What is the difference between Motivation and Applicability

I cannot see major difference based on the current text for them:

1. Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
2. Applicability: Situations in which this pattern is usable; the context for the pattern.

overlapping between fundamental design patterns and others

I found several patterns appear in both fundamental design and others, like composite pattern(in structural), proxy pattern (in structural). Should we delete them from one of the categories? --Leo 17:01, 18 August 2007 (UTC)

Functional Design

It describes a paradigm(more like a recommendation) not a pattern. I don't know how it goes along with the other well specified patterns.

Very much a point of view question. Patterns are tactics, paradims strategies. Like in warfare the two mix up quite effectively. -- 212.213.204.99 (talk) 04:04, 5 December 2007 (UTC)

Comparison of Patterns, removing cruft

I migrated to a comparison of design patterns. This could go in another page and we might add a column for Fowler since he seems to want about Java programmers to remember about a jillion patterns. I aggressively removed several "patterns" which are the handiwork of a few people who would like to go down in history for creating yet another design pattern. These are not patterns. Linking to a few websites by self declared "Java Design Pattern Experts" and the like is NOT sufficient to establish your pet concept as a software design pattern. Given that this is a computing-related subject, we need a more authoritative source, such as http://martinfowler.com/eaaCatalog/. Mistercupcake (talk) 10:03, 29 December 2007 (UTC)

I just removed Mistercupcake's comment about Fair Use from the top of the comparison, as we don't discuss that sort of stuff in the article. But here's what he wrote, in case it becomes interesting in the future:

Some of these descriptions are taken from Design Patterns according to Wikipedia's fair use guidelines

RossPatterson (talk) 15:31, 29 December 2007 (UTC)

Cleaning up Design Pattern Articles

It occurred to me as I was browsing the articles on Factory, Builder, and Abstract Factory that including source code from various programming languages makes the individual design pattern articles much less appealing: there are too many languages (I really don't care about how to make a Builder in Visual Prolog) and example code is BULKY. There is an argument for separating and consolidating example code from the individual design pattern articles: no one has to agree on which language gets to be the "authoritative reference" for a given pattern. We can just include links from the pattern article to the correct subsection of the example code article for each language for which example code for that pattern exists.

In other words: move example source code from design pattern articles to articles titled "Java Examples of Design Patterns", "C++ Examples of Design Patterns", "Visual Prolog Examples of Design Patterns", etc...

Thoughts? Mistercupcake (talk) 19:44, 18 January 2008 (UTC)

Examples don't even belong in Wikipedia. They belong in something else like Wikibooks. 64.91.186.214 (talk) 18:09, 9 March 2008 (UTC)

The problem isn't that the articles have examples, the problem is that the articles have code that stands in place of explanations of the pattern. For example, from Factory method pattern:

Consider as an example a program to read image files and make thumbnails out of them. The program supports different image formats, represented by a reader class for each format:

public interface ImageReader 
{
     public DecodedImage getDecodedImage();
}
 
public class GifReader implements ImageReader 
{
     public GifReader( InputStream in ) 
     {
         // check that it's a gif, throw exception if it's not, then if it is
         // decode it.
     }
 
     public DecodedImage getDecodedImage() 
     {
        return decodedImage;
     }
}
 
public class JpegReader implements ImageReader 
{
     //....
}

instead of something more like:

Consider as an example a program to read image files and make thumbnails out of them. The program supports different image formats, represented by a reader class for each format. Such subclasses would be named subtypeReader (e.g.. GifReader, JpegReader). Each subclass provides a constructor and implementations of the key methods of the superclass, such as getDecodedImage().

RossPatterson (talk) 00:44, 11 March 2008 (UTC)

I actually find the code examples more helpful than the text. I, and I don't think I'm alone, can understand what the pattern does better if I see it in action than if it is just being talked about. I do like the fact there is an introduction and some UML diagrams and such, but I get a far better understanding from seeing an example in code, therefore I think it deserves to be in the article. Maybe you could section off the examples so all coding examples on the page could be collapsed? And then do the same for the textual explanation. That way the user could decide which one to look at (or both). --BluePlateSpecial (talk) 02:29, 1 December 2008 (UTC)

"client"

What's a "client"? The term is used several times in this article, in the table in the Classification section. It doesn't read like one could just link to Client (computing)? I've looked around, following the links to the different design patterns in the table where the description mentions "client", and i've found in Command pattern#Terminology, but that ain't much. Then i see the term used and somewhat explained in Class (computer science) and Object-oriented programming, and that explains it a bit more. Still...
Thanks in advance? --Jerome Potts (talk) 20:55, 16 April 2008 (UTC)

why business delegate isn't in the article?

i'm so confused.isn't business delegate a design pattern? —Preceding unsigned comment added by Felisberto (talk • contribs) 23:38, 29 July 2008 (UTC)

Why is this computer science and not software engineering?

I think all of the software engineering materials should be taken out of the computer science department. It's like putting electrical engineering items with physics articles about electricity. Moshewe (talk) 21:23, 14 August 2008 (UTC)

as3 design patterns

well, that was not spam. its realy helpfull: http://code.google.com/p/insnet-lab/ —Preceding unsigned comment added by 85.176.13.209 (talk) 14:28, 11 October 2008 (UTC)