We already saw what design patterns are and took a look at creational patterns in earlier articles. Today we’ll deal with the second category: structural patterns.

These design patterns are all about class and object composition. Class-creation patterns use inheritance to compose interfaces, whilst object patterns define ways to compose objects to obtain new functionality. All of these patterns aim to ease the design by identifying a simple way to realize relationships between entities.

The most common structural patterns are:

Adapter

An off the shelf component may offer interesting functionality that you may want to reuse, but its view of the world is not compatible with the philosophy and architecture of the system currently being developed. This is where the Adapter Pattern steps in.

This pattern is about creating an intermediary abstraction that translates, or maps, the old component to the new system. Clients call methods on the Adapter object, which redirects them into calls to the legacy component.

Bridge

The Bridge Pattern decomposes the original component’s interface and implementation into different class hierarchies. The interface class contains a pointer to the abstract implementation class. This pointer is initialized with an instance of a particular implementation class, but all subsequent interaction from the interface class to the implementation class is limited to the abstraction maintained in the implementation base class. The client interacts with the interface class, and it in turn “delegates” all requests to the implementation class.

The interface object is the handle known and used by the client. The implementation object, or body, is encapsulated to ensure that it may continue to evolve, or be entirely replaced.

Composite

The Composite Pattern might be used when an application needs to manipulate a hierarchical collection of objects of different types: different types of objects are handled in different ways, and querying the type of each object before processing it is not desirable.

This pattern is implemented by defining an abstract base class that specifies the behavior that needs to be performed upon all primitive and composite objects. Then, primitive and composite classes must be subclassed off of the Component class. Each composite object couples itself only to the abstract type component.

This pattern should be used when you have composites that contain components, each of which could be a composite.

Decorator

The Decorator Pattern can be used when a particular behavior or state must be applied to individual objects at run-time – in this case inheritance cannot be used because it is static.

The original object must be encapsulated inside an abstract wrapper interface, from which both the core and the decorator object inherit. The interface then uses recursive composition to allow an unlimited number of decorator layers to be added to each core object.

Note that this pattern allows functionality to be added to an object, not methods to an object’s interface. The interface presented to the client must remain constant as successive layers are specified.

Facade

When a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem, you can use the Facade Pattern: this kind of software design encapsulates a complex subsystem within a single interface object.

The Facade Pattern defines a unified, higher level interface to a subsystem that makes it easier to use. This way, the learning curve necessary to successfully leverage the subsystem is reduced. It also promotes decoupling the subsystem from its potentially many clients. On the other hand, if the Facade is the only access point for the subsystem, it will limit the features and flexibility that power users might need.

Flyweight

The Flyweight Pattern is designed to solve problems related to granularity and performance: use it when designing objects down to the lowest levels of system granularity, with those objects being extremely expensive in terms of performance.

This pattern describes how to share objects to allow their use at fine granularities without prohibitive cost. Each Flyweight object is divided into two pieces: intrinsic (stateless) and extrinsic (state-dependent). Intrinsic state is stored in the Flyweight object. Extrinsic state is stored or computed by client objects, and passed to the Flyweight when its operations are invoked.

Flyweights are stored in a Factory’s repository. The client doesn’t create Flyweights directly, but requests them from the Factory. Each Flyweight cannot stand on its own. Any attributes that would make sharing impossible must be supplied by the client whenever a request is made of the Flyweight. The Flyweight uses sharing to support large numbers of objects efficiently.

Proxy

If you need to support resource-hungry objects, and you do not want to instantiate them unless and until they are absolutely necessary, you can use the Proxy Pattern.

The Proxy object instantiate some real object the first time the client makes a request of the proxy, remembers the identity of this real object, and forwards the request to it. Then, all subsequent requests are simply forwarded directly to the encapsulated real object. Implemented as an interface, the presence of the Proxy object standing in place of the real object is transparent to the client.

Continue reading Software design patterns (IV): behavioral patterns »

Further reading

Related posts:

  1. Software design patterns (II): creational patterns
  2. Software design patterns (IV): behavioral patterns
  3. Software design patterns (I)