Content deleted Content added
Elaboration of cited resource in the "History" section |
Moti Barski (talk | contribs) |
||
| (35 intermediate revisions by 16 users not shown) | |||
Line 1:
{{short description|Reusable solution to a commonly occurring software problem}}
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=
[[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}}
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}}
==History==
Patterns originated as an [[Pattern (architecture)|architectural concept]] by [[Christopher Alexander]] as early as 1977 in [[A Pattern Language]] (
| last = Smith
| first = Reid
Line 131:
}}</ref>
== Practice ==
Design patterns can speed up the development process by providing proven development paradigms.<ref>{{cite web
Line 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
=== [[Creational patterns
{| class="wikitable"
|-
Line 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 420 ⟶ 426:
|}
=== [[Behavioral patterns
{| class="wikitable"
|-
Line 526 ⟶ 532:
|}
=== [[Concurrency patterns]] ===
{| class="wikitable"
|-
Line 739 ⟶ 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 750 ⟶ 764:
*[[Design pattern]]
*[[Distributed design patterns]]
*
*[[Enterprise Architecture framework]]
*[[GRASP (object-oriented design)]]
Line 756 ⟶ 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]]
| |||