Software design pattern: Difference between revisions

Revision as of 06:26, 28 November 2024

Latest revision as of 11:10, 14 August 2025

(39 intermediate revisions by 18 users not shown)

Line 1:

{{short description|Reusable designsolution forto writinga codecommonly that provides aoccurring well-definedsoftware functionproblem}}

In [[software engineering]], a '''software design pattern''' or '''design pattern''' is a general, [[reusability|reusable]] solution to a commonly occurring problem in many contexts in [[software design]].<ref>{{cite book |last=Alexandrescu |first=Andrei |date=2001 |title=Modern C++ Design: Generic Programming and Design Patterns Applied |publisher=Addison-Wesley |page=xviii |isbn=978-0-201-70431-0}}</ref> A design pattern is not a rigid structure to be transplanted directly into [[source code]]. Rather, it is a description or a template for solving a particular type of problem that can be deployed in many different situations.<ref>{{cite book |last=Horner |first=Mark |date=2005 |title=Pro .NET 2.0 Code and Design Standards in C# |publisher=Apress |chapter=9 |page=171|isbn=978-1-59059-560-2 }}</ref> Design patterns can be viewed as formalized [[best practice]]s that the programmer may use to solve common problems when designing a software application or system.

In [[software engineering]], a '''Design Pattern''' describes a relatively small, well-defined aspect (i.e. functionality) of a [[computer program]] in terms of how to [[computer programming|write]] the [[source code|code]].

[[Object-oriented programming|Object-oriented]] design patterns typically show relationships and interactions between [[class (computer science)|class]]es or [[object (computer science)|object]]s, without specifying the final application classes or objects that are involved.{{Citation needed|date=January 2025}} Patterns that imply mutable state may be unsuited for [[functional programming]] languages. Some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.{{Citation needed|date=January 2025}}

Using a pattern is intended to leverage an existing [[concept]] rather than [[re-inventing the wheel|re-inventing]] it. This can decrease the time to [[software development|develop software]] and increase the [[Quality (business)|quality]] of the resulting program.

Design patterns may be viewed as a structured approach to [[computer programming]] intermediate between the levels of a [[programming paradigm]] and a concrete [[algorithm]].{{Citation needed|date=January 2025}}

Notably, a pattern does ''not'' consist of a [[software artifact]]. Most development resources that a [[programmer]] uses involve configuring the [[codebase]] to use an artifact; for example a [[software library|library]]. In contrast, to use a pattern, a programmer writes code as described by the pattern. The result is unique every time even though the result may be recognizable as based on the pattern.

Some consider using patterns to be [[best practice]] for [[software design]].

Some consider using design patterns as a structured approach to [[computer programming]].

Conceptually, design pattern may be described as more specific than [[programming paradigm]] and less specific than [[algorithm]].

==History==

Patterns originated as an [[Pattern (architecture)|architectural concept]] by [[Christopher Alexander]] as early as 1977 in [[A Pattern Language]] (c.fcf. his article, "The Pattern of Streets," JOURNAL OF THE AIP, September, 1966, Vol. 32, No. 5, pp.&nbsp;273–278). In 1987, [[Kent Beck]] and [[Ward Cunningham]] began experimenting with the idea of applying patterns to programming – specifically [[pattern language]]s – and presented their results at the [[OOPSLA]] conference that year.<ref name = "Smith1987">{{cite conference

| last = Smith

| first = Reid

Line 32 ⟶ 27:

| access-date = 2006-05-26}}</ref> In the following years, Beck, Cunningham and others followed up on this work.

Design patterns gained popularity in [[computer science]] after the book [[Design Patterns|''Design Patterns: Elements of Reusable Object-Oriented Software'']] was published in 1994 <!-- 1994, not 1995. See talk page. --> by the so-called "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson and etJohn al.Vlissides), which is frequently abbreviated as "GoF". That same year, the first [[Pattern Languages of Programming]] Conference was held, and the following year the [[Portland Pattern Repository]] was set up for documentation of design patterns. The scope of the term remains a matter of dispute. Notable books in the design pattern genre include:

* {{cite book

Line 136 ⟶ 131:

}}</ref>

== Practice ==

Design patterns can speed up the development process by providing proven development paradigms.<ref>{{cite web

Line 202 ⟶ 197:

== Object-oriented programming ==

[[Object-oriented programming|Object-oriented]] design patterns typically show relationships and interactions between [[class (computer science)|class]]es or [[object (computer science)|object]]s, without specifying the final application classes or objects that are involved. Patterns that imply mutable state may be unsuited for [[functional programming]] languages. Some patterns can be rendered unnecessary in languages that have built-in support for solving the problem they are trying to solve, and object-oriented patterns are not necessarily suitable for non-object-oriented languages.

==Examples==

Design patterns can be organized into groups based on what kind of problem they solve. [[Creational pattern]]s create objects. [[Structural pattern]]s organize classes and objects to form larger structures that provide new functionality. [[Behavioral pattern]]s providedescribe communicationcollaboration between objects and realizing these patterns.

=== [[Creational patterns|Creational pattern]] ===

{| class="wikitable"

|-

Line 298 ⟶ 293:

| {{yes}}

| {{yes}}

|-

| [[LivinGrimoire]]

| modularly absorbs skills(features/abilities) with one line of code per skill

| {{no}}

| {{no}}

| {{yes|{{cite web | url=https://github.com/yotamarker/LivinGrimoire/wiki | title=LivinGrimoire software pattern | website=GitHub}}}}

|}

Line 425 ⟶ 426:

|}

=== [[Behavioral patterns|Behavioral pattern]] ===

{| class="wikitable"

|-

Line 531 ⟶ 532:

|}

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

{| class="wikitable"

|-

Line 744 ⟶ 745:

In order to achieve flexibility, design patterns may introduce additional levels of [[indirection]], which may complicate the resulting design and decrease [[Runtime (program lifecycle phase)|runtime]] performance.

== Relationship to other topics ==

Software design patterns offer finer granularity compared to software architecture patterns and software architecture styles, as design patterns focus on solving detailed, low-level design problems within individual components or subsystems. Examples include Singleton, Factory Method, and Observer. <ref name="O'Reilly Media">{{Cite book |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |year=2020 |isbn=978-1492043454}}</ref><ref name=":0">{{Cite book |title=Design Patterns: Elements of Reusable Object-Oriented Software |isbn=978-0201633610}}</ref><ref name=":1">{{Cite book |title=Patterns of Enterprise Application Architecture |isbn=978-0321127426}}</ref>

[[List of software architecture styles and patterns|Software Architecture Pattern]] refers to a reusable, proven solution to a recurring problem at the system level, addressing concerns related to the overall structure, component interactions, and quality attributes of the system.{{Citation needed|date=January 2025}} Software architecture patterns operate at a higher level of abstraction than design patterns, solving broader system-level challenges. While these patterns typically affect system-level concerns, the distinction between architectural patterns and architectural styles can sometimes be blurry. Examples include [[Circuit breaker design pattern|Circuit Breaker]]. <ref name="O'Reilly Media" /><ref name=":0" /><ref name=":1" />

[[List of software architecture styles and patterns|Software Architecture Style]] refers to a high-level structural organization that defines the overall system organization, specifying how components are organized, how they interact, and the constraints on those interactions.{{Citation needed|date=January 2025}} Architecture styles typically include a vocabulary of component and connector types, as well as semantic models for interpreting the system's properties. These styles represent the most coarse-grained level of system organization. Examples include [[Multitier architecture|Layered Architecture]], [[Microservices]], and [[Event-driven architecture|Event-Driven Architecture]]. <ref name="O'Reilly Media" /><ref name=":0" /><ref name=":1" />

==See also==

Line 755 ⟶ 764:

*[[Design pattern]]

*[[Distributed design patterns]]

*[[Double-chance function]]

*[[Enterprise Architecture framework]]

*[[GRASP (object-oriented design)]]

Line 761 ⟶ 770:

*[[Programming idiom|Idiom]] in programming

*[[Interaction design pattern]]

*[[List of software architecture styles and patterns]]

*[[List of software development philosophies]]

*[[List of software engineering topics]]