Software design pattern: Difference between revisions

Revision as of 12:37, 24 April 2025

Latest revision as of 11:10, 14 August 2025

(13 intermediate revisions by 8 users not shown)

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.

[[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}}

Line 9:

==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 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==

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 758 ⟶ 764:

*[[Design pattern]]

*[[Distributed design patterns]]

*[[Double-chance function]]

*[[Enterprise Architecture framework]]

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