Design Patterns
Design Patterns
Some topics that categorize DesignPatterns into the GangOfFour categories:
Given that patterns could be applied to many different disciplines, I would suggest that we talk about SoftwareDesignPatterns, to differentiate from ArchitecturalDesignPatterns or other kinds. Then the question is, are there any design patterns that work across specific disciplines? I doubt it, although there may be some "meta" patterns...
Why it is easier to find an AntiPattern than a DesignPattern or an AmeliorationPattern in this Wiki?
Maybe because it is easier to look at something one has done and say "Oh, I shouldn't have done that" than it is to look at something one has done and say "My, that was successful. What made it such a success was..." I think it's the same reason it's easier to tell somebody what not to do than what to do.
Maybe this is the same reason why there are basically much more ways to insert bugs in code than to insert correct statements :) -- FlavioPoletti
Isn't the definition or existence of a problem a preceeding step to finding a solution? So to find a successful pattern you have to have first determined some failed approaches which offer needed contrast. Also, it is intuitively persuading to think that there are more ways to fail than to succeed.
The SoftwareDesignPatternsIndex may be a page you are looking for. It lists at least quite a few of the "design patterns specific to SoftwareEngineering", as described at the SoftwareDesignPatterns page. The Index is not automated, so it may be out of date, and there you are free to update it, if you find it so.
MarkJasonDominus has apparently prepared a 5-minute lecture in which he questions whether the people in the SoftwareDesignPatterns movement are really doing what ChristopherAlexander was talking about. To the extent one can get the gist of his argument from the web version of his slides at http://perl.plover.com/yak/design/, what do the folks around here think of it?
TinyWiki, the PerlPatternsRepository, http://wiki.slowass.net/?DesignPatterns enumerates some differences between ChristopherAlexander's DesignPatterns and the GangOfFour's version. It doesn't belong in black and white, but there are differences, and apparently a need to defend what PerlPatternsRepository is doing. -- ScottWalters
This is an old, old argument in the Software patterns community. This subject has been brought up and rehashed at every single PLoP (and probably EuroPLoP) conference since the very first one. In fact, the PatternLanguagesOfPrograms? conference was founded to try to move the community more towards PatternLanguages and away from pattern catalogs. However, that's still not been enough for some people. The consensus of the patterns community has been "we know...we're going to do our thing anyway..." -- KyleBrown
I am yet to see a design pattern (only SoftwareDesignPatterns ;-) ) which is a major variation from the 23 patterns Gamma et al. have documented. If you have one, please provide a link here. Patterns resulting from a combination of different patterns from the DesignPatternsBook need not be listed here. Moreover, patterns listed here must be general and not tied to specific environments.
The GangOfFour book didn't invent all those DesignPatterns you know. They went out and tried to document the most fundamental object oriented DesignPatterns they could find over several years. I'm not sure what would be achieved by searching for DesignPatterns that someone sufficiently bloody-minded couldn't claim was linked to one of the 23. Besides there's also the effect that people who've been exposed to the DesignPatternsBook will tend to see new patterns in terms of their relationship to the 23. It would be like trying to discover a new colour. Someone will always be able to say "actually that's just a grey-green-blue." -- AdewaleOshineye
One can argue that many of the GoF patterns are not fundamental to OO design, but rather work around limitations in particular implementations of OO. For example, several patterns in the GoF book that work well in Java or C++ are unneeded in languages with a more powerful OO approach; especially the creational patterns, which are very much to do with getting around the problems of constructors in C++, Java, C#, etc., not working just like any other method. (cf. AreDesignPatternsMissingLanguageFeatures)
That's an old, weak argument usually put forward by those who either don't understand the patterns much or haven't thought deeply about the capabilities of those languages. For instance read the section on the creational patterns in the DesignPatternsSmalltalkCompanion for a strong set of reasons why the creational patterns are necessary even in Smalltalk, which is free of C++ constructor sematics --KyleBrown
Weak? How is it weak? Where's the hole in the argument? I have a similar response to many of the creational patterns: for example, the AbstractFactoryPattern is great in Java, but rarely necessary in a language such as RubyLanguage (or, I thought, SmalltalkLanguage), in which classes are first-class objects and can be passed around and receive messages even if their identity is not known a priori. Likewise, VisitorPattern is a workaround for closed classes, and thus isn't particularly useful in a language with open classes. To be sure, some of the GoF patterns (like the CommandPattern) are useful in any language, but they are IMHO in the minority. --MarnenLaibowKoser (ArguingWithGhosts)
Although I understand that Gamma et al. did not invent those patterns, I would like to see a variation from the already well known patterns, which IMHO, would be more educative. As the 23 patterns are well known, it is easier to grasp related patterns.
Interesting question. I dug out my Gamma et al, and looked at the back cover. Shows a diagram of the 23 design patterns. After several years of being around patterns, these 23 patterns seem low level -- at the level of two or three objects interacting with each other.
For higher-level patterns, I dug out Plop and Plop 2. My favorite pattern from Plop is #2: A Pattern Language for Tool Construction and Integration Based on the Tools and Materials Metaphor.
This is right in line with Alexander's notions, because a PatternLanguage is supposed to include patterns for all levels of granularity. You select one that is fairly general to handle a general problem, then use progressively finer grained patterns as you get to more detailed levels of design. So what you say indicates that these software design patterns are in fact patterns in the Alexander sense. - TomPassin?
Then I pondered. Are there other low-level patterns I am familiar with? I thought of parsing and state machines. Gamma et al does have an Interpreter which you can use to parse a simple grammar, but doesn't seem to have other parser or state machine patterns. But I have never coded a parser or state machine with objects, except by using the Interpreter approach. Oh, well.
I pondered some more. The way VisualWorks Smalltalk handles copy, by creating an empty new object and then calling the method postCopy on the new object, is very handy. PostCopyMethod? is my candidate for a useful, simple, low-level pattern not in Gamma.
I think the original author has simply not looked very hard. There are plenty of patterns discussed in Wiki, most can be found with CategoryPattern. There is KentBeck's SmalltalkBestPracticePatterns, there's MartinFowler's AnalysisPatterns, there's the PatternLanguagesOfProgramDesign books. There's even the ShieldPattern, which I would call a fundamental programming pattern.
Just curious: any chance that patterns could come with example unit tests? I don't expect cookie-cutter unit tests in all available languages that would work 100% of the time for everyone, but I am thinking that, given a pattern, perhaps a suite of unit tests written in Java that could be used as a basis for creating your own unit tests? Or maybe just a UnitTestPatternLanguage? that would describe the different types of unit tests you should expect to use when developing a solution using a particular pattern. The most obvious to me would be for instance in the Singleton pattern, you would have a unit test to ensure that only one instance of the object is ever created, etc. Just a thought.
As a further note, the more I'm exploring unit tests, the more fun I'm having. I'd like to get into patterns more, but I also think that if a particular problem can have a particular architectural solution (a pattern), then that pattern can have a particular set of unit tests. Essentially think of it as a litmus test -- if your architecture can pass the unit tests for ABC, then it can be considered ABC pattern.
The tests don't have to be in code. In fact, I'd prefer them to be in prose form, so that we can then convert them into code ourselves for our particular testing frameworks. Then individuals could look at the pattern, see that there is a prose description of test X but no code in language Y for test X, so they implement the test in language Y and submit it back to the archive for inclusion. Then when you or I come along and want to test we already have the code available.
Of course we customize patterns for our own internal use, but given a standard set of unit tests for a pattern, as long as your code passes those tests you are still considered to be using that pattern.
OK I'm rambling quite a bit here, but hopefully you get the idea...
I think that automated JUnit tests for at least the most obvious and well-known patterns would be a great idea but I also do think that the patterns themselves may serve as the "prose" of a unit test as they fairly well do describe / specify the pattern. Automated JUnit test creation however is quite difficult, given that a pattern can be occluded by other patterns also implemented in one unit, unless you require certain base classes or interfaces to be present. However, with UML and J2SE 1.5 and other languages that support attributed methods, fields and classes, it could be made possible and likewise be automated by some generic test tool - that would at least require some additional configuration or perhaps user-implemented callbacks - call it a framework.
I'm also interested in patterns for unit testing. Developers trying to adopt XP practices find writing the unit tests as hard (or harder) than writing the objects under test. Finding ways to automate testing with things like JUnit requires some pretty good lateral thinking (and patience). I'd be interested to hear about anyone that has done a lot of unit testing and accumulated common patterns that crop up again and again; e.g. how to unit test web page content (ignoring layout). -- MikeHowells
I created an IRC channel solely for the discussion of implementing, and thinking about solving SoftwareDesign issues with DesignPatterns. The server is located at irc.freenode.net and the channel name is #design-patterns. Please join everyone in this room for anything related to design patterns. -- JimHodapp?
Considering the UnderstandingPattern? of a newbie to patterns, could be useful a TopDownApproach? for the presentation of DesignPatterns. That means that the start point should be the definition of an AbstractPattern? or similar term, in order to wake up the interest to DesignPatterns of the reader. If the reader is not conscious, that we are surrounded by patterns, if we, for example, do not point that the nature is build up from lots of patterns, then we will not convince him that easily about the importance of using them. This opinion is based on experience.
Even if this wikiwikiwiki does focus on DesignPatterns, their use, their categories etc., and was not thought to be a tutorial for a newbie, it should be a way to attract new people to this way of thinking and acting. Each of us had to have started somewhere with Design Patterns, even the master of this website
--MihalyElekes?
To start with, a SoftwareDesignPattern is not something that anyone can �design?since is something that must be discovered.
A SoftwareDesignPattern is essentially a collaboration of classes, or the realization of a use case, but not any collaboration of classes can become a SoftwareDesignPattern.
It must be discovered (determined by somebody) that it is general enough to be useful and applicable to lots of situations in systems design and development.
A few brilliant guys identified the first ones, that were, in retrospective, the easiest to get. As time went by, the ones left were more and more difficult to discover, so what has been said about patterns and time is correct, but the inference produced does not stand. As time passes by, it takes much more effort to discover new patterns. --- GastonNusimovich
Just a short note to the Wikizens...
I received the latest copy of the UtneReader yesterday (Nov.-Dec. 2004) and was pleased to see an article/review in there regarding the publication of volume 3 of ChristopherAlexander's The NatureOfOrder (volumes 1, 2, and 4 having already been published). The article said that this 2150 page set provides a theoretical basis for the selection of patterns in Alexander's A PatternLanguage and for the creation of new patterns.
-- JoeBradley
May design patterns eventually become subject to SoftwarePatent or LogicPatent? issues?
2005-July-30: News flash (scoop goes to slashdot according to http://news.google.com/, which on this topic shows only the slashdot story so far):
"ACM's Special Interest Group on Programming Languages (SIGPLAN) recently awarded the 2005 Programming Languages Achievement Award to Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the 'Gang of Four') for their creation of 'Design Patterns' (the computer science book and the subfield at the intersection of programming languages and software engineering). The annual award recognizes an individual (or individuals) who has (have) made a significant and lasting contribution to the field of programming languages."
Awardee home pages/person pages here on c2:
See especially GangOfFour, DesignPatternsBook, PrintableDesignPatternReferenceCards are freely available online
See: CategoryRefactoring, HypermediaDesignPatternsRepository, AmeliorationPattern, DesignPatternsConsideredHarmful, AreDesignPatternsMissingLanguageFeatures, WhenIsTheUseOfDesignPatternsNotAppropriate, SoftwareDesignPatternsIndex (with cross references to different names for the same pattern)
CategoryPattern (an index of pattern topics) CategoryDesign
Other external references: http://en.wikipedia.org/wiki/Design_pattern_(computer_science), PatternImplementations (RubyLanguage wiki)
Does wiki ever talk about the design patterns themselves or just meta-talk about what a pattern even is?
Wiki doesn't talk about anything. People contribute as they want and that builds up over the years. There is a lot of material here.
EditText of this page
(last edited August 26, 2013)
or FindPage with title or text search