imported>Stevebroshar: /* Examples */ Less bullets; more objective wording

2025-12-15T15:40:56Z

Examples: Less bullets; more objective wording

← Previous revision		Revision as of 15:40, 15 December 2025
Line 1:		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 ~~among~~ entities.		A '''structural pattern''' is a [[software design pattern]] that encapsulates relationships between entities.

	Examples ~~of Structural Patterns~~ include:		==Examples==
			Examples include:

	* [[Adapter pattern]]: ~~'adapts'~~ one interface for a class into one that a client expects		; [[Adapter pattern]]: Adapts one interface for a class into one that a client expects.
	** Adapter pipeline: Use multiple adapters for debugging purposes.<ref>{{cite web		:; Adapter pipeline: Use multiple adapters for debugging purposes.<ref>{{cite web
	\| url = http://c2.com/		\| url = http://c2.com/
	\| title = Adapter Pipeline		\| title = Adapter Pipeline
Line 13:		Line 14:
	\| access-date = 2012-07-20		\| access-date = 2012-07-20
	}}</ref>		}}</ref>
	** Retrofit Interface Pattern:<ref>{{cite web		:; Retrofit Interface Pattern: An adapter used as a new interface for multiple classes at the same time.<ref>{{cite web
	\| url = http://c2.com/		\| url = http://c2.com/
	\| title = Retrofit Interface Pattern		\| title = Retrofit Interface Pattern
Line 31:		Line 32:
	\| archive-date = 2010-12-31		\| archive-date = 2010-12-31
	\| access-date = 2012-07-20		\| access-date = 2012-07-20
	}}</ref> ~~An adapter used as a new interface for multiple classes at the same time.~~		}}</ref>
	* [[Aggregate pattern]]: a version of the [[Composite pattern]] with methods for aggregation of children		; [[Aggregate pattern]]: A version of the [[Composite pattern]] with methods for aggregation of children.
	* [[Bridge pattern]]: decouple an abstraction from its implementation so that the two can vary independently		; [[Bridge pattern]]: decouple an abstraction from its implementation so that the two can vary independently.
	** Tombstone: An intermediate "lookup" object contains the real location of an object.<ref>{{cite web		:; Tombstone: An intermediate lookup object contains the real location of an object.<ref>{{cite web
	\| url = http://c2.com/		\| url = http://c2.com/
	\| title = Tomb Stone		\| title = Tomb Stone
Line 43:		Line 44:
	\| access-date = 2012-07-20		\| access-date = 2012-07-20
	}}</ref>		}}</ref>
	* [[Composite pattern]]: a tree structure of objects where every object has the same interface		; [[Composite pattern]]: A tree structure of objects where every object has the same interface.
	* [[Decorator pattern]]: ~~add~~ additional functionality to an object at runtime where subclassing would result in an exponential rise of new classes		; [[Decorator pattern]]: Supports adding additional functionality to an object at runtime. Prevents issue where subclassing would result in an exponential rise of new classes.
	* [[Extensibility pattern]]: a.k.a. ~~Framework - hide~~ complex code behind a simple interface		; [[Extensibility pattern]]: a.k.a. framework, Hides complex code behind a simple interface.
	* [[Facade pattern]]: ~~create~~ a simplified interface of an existing interface to ease usage for common tasks		; [[Facade pattern]]: Creates a simplified interface of an existing interface to ease usage for common tasks.
	* [[Flyweight pattern]]: a large quantity of objects share a common properties object to save space		; [[Flyweight pattern]]: A large 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.		; [[Marker interface 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		; [[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		; [[Opaque pointer]]: A pointer to an undeclared or private type, to hide implementation details.
	* [[Proxy pattern]]: a class functioning as an interface to another thing		; [[Proxy pattern]]: A class functioning as an interface to another thing.

	==See also==		==See also==
	* [[Abstract Document Pattern]]
	* [[Behavioral pattern]]		* [[Behavioral pattern]]
	* [[Concurrency pattern]]		* [[Concurrency pattern]]

imported>Pancho507: /* See also */ add Abstract Document Pattern

2024-05-02T00:27:53Z

See also: add Abstract Document Pattern

New page

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 among entities.

Examples of Structural Patterns include:

* [[Adapter pattern]]: 'adapts' one interface for a class into one that a client expects
** Adapter pipeline: Use multiple adapters for debugging purposes.<ref>{{cite web
| url = http://c2.com/
| title = Adapter Pipeline
| date = 2010-12-31
| publisher = Cunningham & Cunningham, Inc.
| archive-url = http://c2.com/cgi/wiki?AdapterPipeline
| archive-date = 2010-12-31
| access-date = 2012-07-20
}}</ref>
** Retrofit Interface Pattern:<ref>{{cite web
| url = http://c2.com/
| title = Retrofit Interface Pattern
| author = BobbyWoolf
| date = 2002-06-19
| publisher = Cunningham & Cunningham, Inc.
| archive-url = http://c2.com/cgi/wiki?RetrofitInterfacePattern
| archive-date = 2002-06-19
| access-date = 2012-07-20
}}</ref><ref>{{cite web
| url = http://c2.com/
| title = External Polymorphism
| author = MartinZarate
| date = 2010-12-31
| publisher = Cunningham & Cunningham, Inc.
| archive-url = http://c2.com/cgi/wiki?ExternalPolymorphism
| archive-date = 2010-12-31
| access-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
* [[Bridge pattern]]: decouple an abstraction from its implementation so that the two can vary independently
** Tombstone: An intermediate "lookup" object contains the real location of an object.<ref>{{cite web
| url = http://c2.com/
| title = Tomb Stone
| date = 2007-06-17
| publisher = Cunningham & Cunningham, Inc.
| archive-url = http://c2.com/cgi/wiki?AdapterPipeline
| archive-date = 2007-06-17
| access-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 an object at runtime where subclassing would result in an exponential rise of new classes
* [[Extensibility pattern]]: a.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 large 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
* [[Proxy pattern]]: a class functioning as an interface to another thing

==See also==
* [[Abstract Document Pattern]]
* [[Behavioral pattern]]
* [[Concurrency pattern]]
* [[Creational pattern]]

==References==
{{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]]

Structural pattern - Revision history

imported>Stevebroshar: /* Examples */ Less bullets; more objective wording

imported>Pancho507: /* See also */ add Abstract Document Pattern