Structural Patterns

Adapter
- Do we have the right stuff but wrong interface.

We use the adapter design pattern where the requirements is to convert

between one interface to another. Adapter pattern is never implemented
when designing a new system but with the changing requirements we have
deferring interfaces then adapter comes into picture.

Typically the class diagram looks like

Example

We have used some library where we have Add function which takes two
integer and provides the sum of them. Now when upgrading the libray we
find that the library has changed the Add function such that it takes 2
floating point number. Now one option could be to change all the client
code where we have used the Add method or other option is to have an
Adapter.

CalcAdapter calls the necessary library function after making the necessary
changes (in our example conversion between the data types)

Bridge
- Do we have one variation using another variation in a varying way.

Decouple an abstraction from its implementation so that two can vary

independently. In strategy pattern we decouple the behavior but in Bridge
we decouple the abstraction.

Typically the class diagram looks like

Example

In Abstract Factory we discussed about the problem of creating a control

library for various operating system. Now creating the library from the
scratch is never a good idea and so we may need to use some of the existing
infrastructure or library available. We may use the XWindow toolkit or
MacWindow toolkit as the base depending on the user platform and toolkit
available.

The DrawRect actually uses the DrawLine function which actually is

dependent on the type of implementation and we seperate the
implementation from the abstraction and have a link ( or bridge ) between
the two.
Composite
- Do we have units and groups and want to treat them the same way.

Compose the objects in a tree structure where individual objects as well as

the composed objects behave uniformly. Composed objects delegates the
requests to the individual leaf objects.

Typically the class diagram looks like

Example

We have some simple graphics and have some graphics which are composed
of these simple graphics and as a client both should behave uniformly.

Folder browsing could be other example where from the client's point of
view its an operation on the folder tree irrespective of its folder ( composite
object ) or file ( leaf object ).

Decorator
- Do we need multiple additional functions we may need to apply, but
which and how many we add varies, without sub classing.

Attach additional responsibilities to an object dynamically. It has the

capability of performing some additional operations before or after the basic
operation.

Typically the class diagram looks like

Example
Say we have a FileReader class where the file can be read based on the
combination of applying any of the formulas like it could be
 Zipped.
 Encrypted.
 Zipped and encrypted.
 encrypted then zipped and ecrypted again.

The solution is Decorator pattern where we apply the options based on the
requirement.

Code: CSharp

FileReader file = new FileReader();

// Zip the File
ZipReader zip = new ZipReader(file);
// Encrypt the zip file
EncryptedReader enc = new EncryptedReader(zip);

enc.Read();

Code: CSharp

FileReader file = new FileReader();

// Encrypt the file
enc = new EncryptedReader(file);
// Zip the encrypted file
zip = new ZipReader(enc);

zip.Read();

We can apply any combination as and when needed and also new methods
of encryption is very simple. Just add the new class as sibling of
EncryptedReader
Facade
- Do we want simplify, beautify or OO-fy an existing class or subsystem.

When client is decoupled from the system using an inter mediator its called
facade. Facade behaves as a door to subsystem and provides a single
interface to complex interface in the subsystem. Here a point to note is that
the subsystem should not have a dependency on the FACADE and if thats
the case then the facade is a part of the sub-system and it should move
into the sub-system and we should have a new facade class.

Also Facade is not the only entry point to the sub-system but is a
convenient point of communication to the subsystem and client can always
have the direct access to the subsystem.
This methods helps in developing the subsystem independently without
affecting the clients using them.

Typically the class diagram looks like

Example

We have a Car System creation where the car is created based on the
complex subsystems like wheel, steering, chassis, body ...
CREATIONAL

Abstract Factory
- Do we need to create families of objects.

Factory method takes care of one product where as the abstract factory

Pattern provides a way to encapsulate a family of products.

Typically the class diagram looks like

Example

We have a requirement where we need to create control library and the

same library supports multiple platforms but the client code should not be

changed if we import from one operating system to the other. The solution

is
The client uses the GuiFactory to get the required factory of the supported

operating system and calls the same Show Method. Now depending on the

platform we change the factory but the client implementation remains the

same. If support for new operating system is to be added we need the new

factory and the exact implementation of the buttons and without changing

the existing code we can support the new platform.

Factory
- Do we need to have derived classes figure out what to instantiate and
decouple client from instantiated class.

Client uses the factory to create products and its the factory which decides
when the actual product is needed for instantiation. This way client
decouples the instance and can be saved from some of the crucial operations
of object copy if the type of object may change after creation.

Typically the class diagram looks like

Example
Who is what?

ComputerFactory (Creator)
ConcreteComputerFactory (ConcreteCreator)
Processor (Product)
ConcreteProcessor (ConcreteProduct)

When the GetProcessor of ComputerFactory is called its the

ConcreteComputerFactory creates the ConcreteProcessor and the creation of
ConcreteProcessor is delayed till we call the GetProcessor() function.

Another good example could be logging, where we create the instance of the
logger factory but instantiate the logger class when actual logging is done.

Prototype
- Do we have too many classes to instantiate / or is the object creation a

cumbersome process.

Mainly we don't create the objects of a class directly but clone the existing
object and change the state of the object as needed. The main application of

such pattern is when the object creation is costly. As an example we have a

database class the constructor sets up the database for the class. Now for

each new user logging to the system once the system is up we don't setup

the database but just clone the first object and change the user specific

details like user name / password to validate the user.

Typically the class diagram looks like

Example
I would not explain here who is what because its pretty much evident.