Structural Patterns provides the flexibility to specify how
objects and classes can interoperate. The following are the sub patterns that
comprise the Structural Patterns group.
·
Adapter
·
Facade
·
Bridge
·
Composite
·
Decorator
·
Flyweight
·
Proxy
·
Adapter
·
Bridge
·
Composite
·
Decorator
·
Flyweight
·
Proxy
The Adapter Pattern allows different classes to inter-operate
even with incompatible interfaces. The Facade Pattern depicts a single class
that represents a high level class in an entire subsystem and makes the
subsystem easier to use. As an example, a Façade design pattern ensures that
we can have a class that can act as a layer between the User Interface Layer
and the Business Service Layer. Thus, it acts as an agent in the sense that it
facilitates the communication between the User Interface Layer and the Business
Service Layer in a typical n–tier application design. It is to be noted here
that both the Adapter and Façade design patterns can be used to change the
interfaces of the classes, thus enabling an easier communication of these
classes from the User Interface Layer.
The Bridge Pattern eliminates the need of adapter classes in
a sub system and decouples an object’s interface from its implementation so
that both can work independent of each other. The Composite Pattern is a
design pattern that is used to compose a tree like structure of simple and
composite objects so that the clients can treat the individual objects and
their compositions in a uniform manner. The Decorator Pattern provides an
alternative for sub classing to extend functionality in a sub system and adds
responsibilities to objects even after construction of the design of the
system. The Flyweight Pattern is a fine-grained instance used for efficient
sharing. The Proxy Pattern shows an object representing another object and,
like the Adapter Design Pattern, it acts as a layer between the client or the
consumer application and the actual object.