Software design pattern: Difference between revisions

Revision as of 22:32, 21 January 2004

Revision as of 16:03, 23 January 2004

Line 3:

'''Design patterns''' are recurring solutions to problems in [[object-oriented design]]. The phrase was introduced to [[computer science]] in the [[1990s]] by the text ''[[Design Patterns]]: elements of reusable [[object-oriented software]]''. The scope of the term remained a matter of dispute into the next decade. [[Algorithms]] are not thought of as design patterns, since they solve implementation problems rather than design ones. Typically, a design pattern is thought to encompass a tight interaction of a few classes and objects.

AInterest primaryin goalsharing of design is topatterns limitin the amountsoftware ofcommunity sourcehas change neededled to change a program'snumber observedof behaviorbooks, butsymposiums, thisand canthe beformation difficultof toWard achieveCunningham's if a designer does not understand the implications of aoriginal design[[wiki]]. The goal of pattern literature is to make the experience of past designers accessible to beginners and others in the field. A book of design patterns presents different solutions in a common format, to provide a language for discussing design issues.

The format has four essential parts, although the names and ordering differ by source:

*Name - the name of the pattern, which eases discussion.

*Problem - the problem the designer faces, given in context.

*Solution - a detailed description of the solution to the problem.

*Consequences - other results, some negative, of applying the pattern.

The original [[wiki]] was established largely to facilitate discussion of design patterns.

==Pattern Format==

The design pattern format has four essential parts, although the names and ordering differ by source:

===Name===

Every pattern needs a name, to provide a language for design discussion.

===Problem===

Recurring circumstances lead to the discovery of this pattern by multiple persons. A primary goal of design is to limit the amount of source change needed to change a program's observed behavior, but this can be difficult to achieve if a designer does not understand the implications of a design.

===Solution===

The solution is described sufficiently for implementation by novices, although the implementation is usually given in general enough terms that it can be adapted to different projects.

===Consequences===

Applying this solution will effect the rest of the project in certain ways, so it is important to mention any common negative or serendipitous side-effects.

==Similar Terms==

Poor (yet unfortunately common) solutions to common problems are sometimes known as '''[[anti-pattern]]s'''.

Line 17 ⟶ 25:

See also [[amelioration pattern]]

==A List of Design Patterns==

Fundamental patterns

===Fundamental patterns===

* [[Delegation pattern]]

* [[Interface pattern]]

Line 24 ⟶ 34:

* [[Marker Interface pattern]]

===Creational patterns ===

* [[Abstract factory pattern]]

* [[Anonymous subroutine objects pattern]]

Line 32 ⟶ 42:

* [[Singleton pattern]] - an object which is unique in its kind in the whole system

===Structural patterns===

* [[Adapter pattern]]

* [[Bridge pattern]]

Line 44 ⟶ 54:

* [[Proxy pattern]]

===Behavioral patterns===

* [[Breadth first recursion]]

* [[Chain of responsibility pattern]]

Line 61 ⟶ 71:

* [[Hierarchical visitor pattern]]

===[[Concurrency]] patterns===

* [[Action at a distance pattern]]

* [[Balking pattern]]

Line 70 ⟶ 80:

* [[Disable job requests while running job pattern]]

===RealTime patterns===

* [[Scheduled task pattern]]

* [[User interface pattern]]