Structural pattern: Difference between revisions

Revision as of 21:59, 11 July 2007

Latest revision as of 21:12, 26 July 2025

(42 intermediate revisions by 39 users not shown)

Line 1:

In [[Softwaresoftware Engineeringengineering]], '''Structuralstructural Designdesign Patternspatterns''' are [[Design pattern (computer science)|Designdesign Patternspatterns]] that ease the design by identifying a simple way to realize relationships betweenamong entities.

{{Cleanup|date=April 2006}}

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 between 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 aan classobject at runtime where subclassing would result in an exponential rise of new classes

* [[Container pattern]]: create objects for the sole purpose of holding other objects and managing them

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

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

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

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

* [[FaçadeFlyweight pattern]]: create a simplifiedlarge interfacequantity of anobjects existingshare interfacea tocommon easeproperties usageobject forto commonsave tasksspace

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

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

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

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

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

* [[Decorator pattern]]: dynamically add behavior

==See also==

* [[Behavioral pattern]]

* [[HelloConcurrency pattern]]

* [[Creational pattern]]

* [[Hello pattern]]

[[Category:Software design patterns]]

==References==

{{soft-eng-stub}}

{{Commons category|Structural software design patterns}}

{{Reflist}}

{{Design Patterns patterns}}

[[bs:Šema strukture]]

[[uk:Структурні шаблони]]

{{DEFAULTSORT:Structural Pattern}}

[[Category:Software design patterns]]

[[Category:Articles with example Java code]]

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