GoF (Gang of Four) structural patterns deal with the way in which classes and objects form larger structures. Structural class patterns use inheritance to compose interfaces or implementations. For example, multiple inheritance dictates that a single class might be a mixture of more than one parent class. Multiple inheritance makes it easier for independently developed class libraries to work together.
The table below describes each of the GoF structural patterns:
Pattern Name | Design Problem Handled | Role | Description |
---|---|---|---|
Adapter | Translate the interface of a class into an interface that clients expect. Adapter eliminates incompatible interfaces, allowing classes to work together that couldn't otherwise. | Target | Defines the set of operations used by the client to abstract a particular request. |
Client | Manipulates the Target object. | ||
Adaptee | Provides a specific adaptation that can be used for a particular request. | ||
Adapter | Provides the glue between a specific target request and a specific Adaptee, which actually handles the request. | ||
Bridge | Provides an abstract mechanism that allows specific implementations of a particular behavior to vary. | Abstraction | Defines the abstract interface to be implemented by the RefinedAbstraction. |
RefinedAbstraction | Implements the operations declared in the Abstraction interface. | ||
Implementor | Defines the abstract interface implemented by the ConcreteImplementor. Abstraction uses the Implementor. | ||
ConcreteImplementor | Implements the operations declared in the Implementor interface. | ||
Composite | Composite allows clients to manipulate objects that can contain other objects in a uniform manner. | Component | Defines the fundamental interface that all objects must implement to participate in the composition. |
Leaf | An object that contains no other objects in relation to the composition. | ||
Composite | An object that contains other objects that conform to the Component interface. | ||
Client | Manipulates the Component object. | ||
Decorator | Dynamically append additional responsibilities to an object. Decorators extend functionality by providing a flexible alternative to subclassing. | Component | Defines the abstract interface that must be implemented by any object that wishes to be dynamically decorated. |
ConcreteComponent | Implements the operations declared in the Component interface. | ||
Decorator | The abstract interface implemented by ConcreteDecorators. | ||
ConcreteDecorator | Implements the operations declared in the Decorator interface. | ||
Facade | Provides a higher level entry point into a potentially complex sub system, thereby making that subsystem more manageable for the client. | Facade | The object responsible for request delegation. |
Subsystem | Implements the specific requests as delegated by the Facade object. | ||
Flyweight | Sharing is used to efficiently support large numbers of fine-grained objects. | Flyweight | Defines an abstract interface used by clients to manipulate state that cannot be shared between ConcreteFlyweights. |
ConcreteFlyweight | Implements the Flyweight interface as well as providing a storage location for state that can be shared. | ||
UnsharedConcreteFlyweight | Implements the Flyweight interface as well as providing a storage location for state that cannot be shared. | ||
FlyweightFactory | Provides operations for creating ConcreteFlyweight objects. | ||
Client | Manipulates the various Flyweight objects. | ||
Proxy | A proxy or placeholder is provided for another object which controls access to it | Proxy | Implements the interface defined by Subject which in turn passes all requests through that interface to the RealSubject. |
Subject | Defines the set of operations that RealSubject and Proxy must implement. |