Structural pattern: Difference between revisions

Revision as of 09:53, 10 June 2013

Latest revision as of 21:12, 26 July 2025

(14 intermediate revisions by 13 users not shown)

Line 1:

In [[software engineering]], '''structural design patterns''' are [[Design pattern (computer science)|design patterns]] that ease the design by identifying a simple way to realize relationships betweenamong entities.

Examples of Structural Patterns include:

Line 7:

| url = http://c2.com/

| title = Adapter Pipeline

| author =

| date = 2010-12-31

| publisher = Cunningham & Cunningham, Inc.

| archiveurlarchive-url = http://c2.com/cgi/wiki?AdapterPipeline

| archivedatearchive-date = 2010-12-31

| accessdateaccess-date = 2012-07-20

}}</ref>

** Retrofit Interface Pattern:<ref>{{cite web

Line 18 ⟶ 17:

| title = Retrofit Interface Pattern

| author = BobbyWoolf

| authorlink = http://c2.com/cgi/wiki?BobbyWoolf

| date = 2002-06-19

| publisher = Cunningham & Cunningham, Inc.

| archiveurlarchive-url = http://c2.com/cgi/wiki?RetrofitInterfacePattern

| archivedatearchive-date = 2002-06-19

| accessdateaccess-date = 2012-07-20

}}</ref><ref>{{cite web

| url = http://c2.com/

| title = External Polymorphism

| author = MartinZarate

| authorlink = http://c2.com/cgi/wiki?MartinZarate

| date = 2010-12-31

| publisher = Cunningham & Cunningham, Inc.

| archiveurlarchive-url = http://c2.com/cgi/wiki?ExternalPolymorphism

| archivedatearchive-date = 2010-12-31

| accessdateaccess-date = 2012-07-20

}}</ref> An adapter used as a new interface for multiple classes at the same time.

* [[Aggregate pattern]]: a version of the [[Composite pattern]] with methods for aggregation of children

Line 40 ⟶ 37:

| url = http://c2.com/

| title = Tomb Stone

| author =

| date = 2007-06-17

| publisher = Cunningham & Cunningham, Inc.

| archiveurlarchive-url = http://c2.com/cgi/wiki?AdapterPipeline

| archivedatearchive-date = 2007-06-17

| accessdateaccess-date = 2012-07-20

}}</ref>

* [[Composite pattern]]: a tree structure of objects where every object has the same interface

* [[Decorator pattern]]: add additional functionality to aan classobject at runtime where subclassing would result in an exponential rise of new classes

* [[Extensibility pattern]]: akaa.k.a. Framework - hide complex code behind a simple interface

* [[Facade pattern]]: create a simplified interface of an existing interface to ease usage for common tasks

* [[Flyweight pattern]]: a highlarge quantity of objects share a common properties object to save space

* [[Marker interface pattern|Marker pattern]]: an empty interface to associate metadata with a class.

* [[Pipes and filters]]: a chain of processes where the output of each process is the input of the next

* [[Opaque pointer]]: a pointer to an undeclared or private type, to hide implementation details

* [[Private class data pattern]]: restrict accessor/mutator access

* [[Proxy pattern]]: a class functioning as an interface to another thing

Line 64 ⟶ 61:

{{Commons category|Structural software design patterns}}

{{Reflist}}

{{Design Patterns patterns}}

{{DEFAULTSORT:Structural Pattern}}

[[Category:Software design patterns]]

[[Category:Articles with example Java code]]

[[Category:Articles with example C Sharp code]]

{{soft-eng-stub}}

[[ar:نماذج التصميم الهيكلية]]