imported>Curlyquote: Punctuation

2025-12-19T03:01:11Z

Punctuation

imported>Not-cheesewhisk3rs: fix reference spacing (MOS:REFPUNCT)

2025-10-16T11:27:53Z

fix reference spacing (MOS:REFPUNCT)

← Previous revision		Revision as of 11:27, 16 October 2025
Line 3:		Line 3:
	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 '''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.

	[[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}}		[[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}}		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}}
Line 197:		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.		[[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==		==Examples==
Line 742:		Line 742:

	== Relationship to other topics ==		== 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>		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 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" />		[[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==		==See also==
Line 758:		Line 758:
	*[[Design pattern]]		*[[Design pattern]]
	*[[Distributed design patterns]]		*[[Distributed design patterns]]
	*[[Double-chance function]]
	*[[Enterprise Architecture framework]]		*[[Enterprise Architecture framework]]
	*[[GRASP (object-oriented design)]]		*[[GRASP (object-oriented design)]]

imported>John of Reading: /* History */ Typo fixing, replaced: c.f. → cf.

2025-05-06T07:53:25Z

History: Typo fixing, replaced: c.f. → cf.

Show changes

Software design pattern - Revision history

imported>Curlyquote: Punctuation

imported>Not-cheesewhisk3rs: fix reference spacing (MOS:REFPUNCT)

imported>John of Reading: /* History */ Typo fixing, replaced: c.f. → cf.