GoF Structural Patterns

See Also

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.
See Also
GoF Design Patterns
GoF Behavioral Patterns
GoF Creational Patterns

Legal Notices