This is a SoftwareDesignPatternCritique.

I just finished reading TheTimelessWayOfBuilding of ChristopherAlexander which introduces A PatternLanguage. It puts the DesignPattern hype into a clear perspective. A critical one. At least for me.

With this view I miss the following important points in the usual SoftwareDesignPattern discussions:

* There aren't patterns for every level of granularity. But to be patterns in Alexanders sense there should be ones for every level from SystemPattern over ArchitecturalPattern to LibraryPattern, CollaborationPattern, AlgorithmPattern down to StructuralPattern, Objectpattern and ByteManipulationPattern maybe.
* The patterns stand too much in isolation. But the key point of Alexander is that they support each other. I don't know if this holds true at all for software patterns.
* There is no real PatternLanguage. The language should tell you which patterns to try and tackle in which order (to ensure that you don't need to backtrack and change larger structures later).
* There is not enough support for AmeliorationPattern''''''s to deal with change. Alexander elaborates on continous repair and change especially on the large scale. But maybe the pattern on the large scale is really ExtremeProgramming.
* The truth of the patterns is that help you learn to write good software, but they are not good by themself. You can do without them if you really understand the needs of the code. 

Maybe this is because there is not yet really a PatternLanguage but only a PatternCollection and the real fun hasn't yet begun.

GunnarZarncke

----
I pulled together some more critical views from the design pattern pages on this wiki. To make my point into a WikiWord:

See also PatternsOfSoftware, where RichardGabriel and ChristopherAlexander himself criticize both software design patterns and also Alexander's original architectural design patterns that inspired the software ones. Alexander believes his earlier efforts failed, and his more recent efforts that he believes have succeeded apparently have yet to influence software design patterns.

(In brief, the failure was due to overly-mechanical execution, people deluding themselves into believing they'd succeeded brilliantly when they'd actually failed, and the lack of but need for beauty, liveness, and growth.)

''Why it is easier to find an AntiPattern than a DesignPattern or an AmeliorationPattern in this Wiki?''

[There are design patterns at different levels of granularity.] 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

A different approach has been taken by ThomasKuehne who in FunctionalPatternSystemForObjectOrientedDesign analyses the relationships between objects and the patterns which they make. This leads to some similar patterns and some different ones. -- JohnFletcher
----
See also ArchitecturalPattern, DesignPatternsArent, DesignPatternsConsideredHarmful.
----
CategoryDesign