Software design pattern: Difference between revisions

Revision as of 02:44, 31 December 2024

Latest revision as of 11:10, 14 August 2025

(30 intermediate revisions by 14 users not shown)

Line 1:

{{short description|Reusable solution to a commonly occurring software problem}}

In [[software engineering]], a '''software design pattern''' refersor to'''design pattern''' is a reusablegeneral, proven[[reusability|reusable]] solution to a specific,commonly recurringoccurring problem typicallyin focusedmany oncontexts component-levelin design, though they can[[software sometimes span multiple componentsdesign]]. Design patterns address specific issues related to object creation, interaction, or behavior. <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><ref name="O'ReillyA Media"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>{{Citecite book |last=Horner |first=Mark |date=2005 |title=FundamentalsPro of.NET Software2.0 Architecture:Code Anand EngineeringDesign ApproachStandards in C# |publisher=O'Reilly MediaApress |yearchapter=20209 |page=171|isbn=978-14920434541-59059-560-2 }}</ref><ref name=":0">{{CiteDesign bookpatterns |title=Designcan Patterns:be Elementsviewed ofas Reusableformalized Object-Oriented[[best Softwarepractice]]s |isbn=978-0201633610}}</ref><refthat name=":1">{{Citethe bookprogrammer |title=Patternsmay ofuse Enterpriseto Applicationsolve Architecturecommon |isbn=978-0321127426}}</ref>problems when designing a software application or system.

[[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]] (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 126 ⟶ 130:

| via = ResearchGate

}}</ref>

== Connections to other topics ==

Software design patterns offer the finest 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" /><ref name=":0" /><ref name=":1" />

[[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. 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. 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" />

== Practice ==

Line 201 ⟶ 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]] ===

Line 297 ⟶ 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 743 ⟶ 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.

== ConnectionsRelationship to other topics ==

Software design patterns offer the finestfiner 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 754 ⟶ 764:

*[[Design pattern]]

*[[Distributed design patterns]]

*[[Double-chance function]]

*[[Enterprise Architecture framework]]

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

Line 760 ⟶ 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]]