See Design Patterns, part one; Introduction to get the definitions and the laws of design patterns.
Structural Patterns define the way objects are connected with other objects so changes in the system do not affect these connections. Again, the low coupling law is the base for the app designs.
There are eight patterns:
- Adapter – converts the interface of a class into another interface clients expect;
- Bridge – separates an object’s interface from its implementation;
- Façade – provides a more comfortable way to deal with a library or bundle of resources;
- Decorator – adds objects responsibilities dynamically;
- Flyweight – reducing the number of objects;
- Proxy – an object representing other object;
- Composite – to compose objects into tree structures to represent part-whole hierarchies;
- Private Class Data – restricts accessor/ mutator access.
Adapter
Adapter converts the interface of a class into another interface clients expect, as any cable adapter you may encountered. Usually you want to reuse an old component that offers compelling functionality, but its “view of the world” is not compatible with the architecture of the system currently being developed.
Reuse has always been painful and elusive, against everything that theorists said – OOP is about reuse, reuse and reuse. There is always something not quite right between the old and the new. It may be physical dimensions or misalignment. It may be timing or synchronization. It may be unfortunate assumptions or competing standards.
Adapter functions as a wrapper or modifier of an existing class. It provides a different or translated view of that class. Adapter provides a different interface to its subject, Proxy provides the same interface. Adapter makes things work after they’re designed, Bridge makes them work before they are.
Proxy
Proxy speaks for other object. It is used to support distributed, controlled or intelligent access.
You can think about Proxy when
- you need to delay the creation of a costly object until it is needed;
- you have to control communication with remote objects;
- you want to control access to objects;
- you may want smart reference to an object – caching, locking etc.
Façade
Façade wraps a complicated subsystem with a simpler interface. An Operating System is a Façade for hardware. An eCommerce site is a Façade for ordering, billing and shipping the goods.
The Façade design captures the complexity and collaborations of the component and delegates to the appropriate methods. The client uses (is coupled to) Façade only.
Adapter and Façade are both wrappers. Façade defines a new interface, whereas Adapter uses an old interface. Adapter wraps a single object, while Façade routinely wraps multiple objects. Façade could front-end a single complex object and Adapter could wrap several legacy objects.
Bridge
The goal of Bridge is to allow you to structure your code so that you can easily add new kinds of front-end objects which are implemented with functionality in new kinds of back-end objects. Therefore, both handle and body can vary independently of each other.
Bridge is really a code-organization tool that allows you to add in any number of new front-end services that implement their operations by delegating to any number of back-end options. Using Bridge, you can accomplish this without the normal combinatorial explosion of possibilities that would otherwise occur.
Flyweight
Some programs require a huge number of objects that have some shared state among them. Each flyweight object can be divided into two pieces: the state-dependent (extrinsic) part and the state-independent (intrinsic) part. Then put them to share that intrinsic part to save memory. The key here is the HUGE number of objects. The simplicity law ask us to get it only if the memory is a pain.
Decorator
Too many classes! Decorators provide a flexible alternative to subclassing for extending functionality. Instead to create all combination at design time, you will add dynamically behavior or state to individual objects at run-time.
Note that this pattern allows responsibilities to be added to an object, not methods to an object’s interface. The interface presented to the client must remain constant as functionalities are specified.
There are some tradeoffs: coding is more complicated when using Decorators. So, try compromise – there will always be certain combinations that you will describe regularly, which would often work exactly as they are, but if you wanted to decorate them then you would use decorators to make the modifications. This will keep your code readable and maintainable.
Private Class Data
- Encapsulate class data initialization!
- Control write access to class attributes!
- Separate data from methods that use it!
Yes, these are the first lessons in coding. And yes, it is about a design pattern, if you check the definition of Design Patterns.
Composite
The common objects relationship in computing – Containers that contain Containees, each of which could be a Container.
Divide your domain concepts into container classes and containee classes. Create a lowest common denominator interface that makes your containers and containees interchangeable. It should specify the behavior that needs to be exercised uniformly across all containee and container objects.
In a larger Composite problems could arise as recursion is always expensive.
G.