Structural Patterns contd. - Bridge, Facade, Flyweight, Proxy Design Patterns

Structural Patterns contd. - Bridge, Facade, Flyweight, Proxy

If you have directly reached to this article then you may like to first go through the first article on structural design patterns which covers what they are all about and discusses Adapter, Decorator, and Composite design patterns in particular.

Bridge Design Pattern

This design pattern is used to achieve the very basic purpose of Object Oriented Programming, which is to separate the interface of a class from its implementation. This approach has the obvious advantage of achieving the flexibility of being able to alter the implementation any time one wants to without affecting the client code using the class. Sounds similar to the Adapter Design Pattern? Well... it's actually similar to that, but the intent is quite different. The Adapter Design Pattern is used to enable the interfaces of one or more classes to look like and be compatible to the interface of a particular class whereas in case Bridge Design Pattern the class is designed in such a way that the interface is fixed and separate from the implementation. Here we don't have one or more classes to make compatible with the interface of some other class instead we separate the interface of a class from its implementation so that we can have the liberty of distributing the interface to be used by clients without being tightly tied to a particular implementation. Any future changes in the implementation won't affect the client code and this requirement can be really crucial in some cases. For example: if the class is being used to display some data then in future the revised implementation may be used provide additional details/graphs. This will only require to replace the older implementation with the newer one.

How can we implement this design pattern? Very simple... by just having an interface and subsequently implementing the interface in one or more classes. We of course need to have a fixed interface otherwise the very purpose of this design pattern to provide the flexibility of having a loosely coupled implementation won't be achieved.

Facade Design Pattern

This design pattern is primarily used to achieve simplicity. The pattern provides a simpler interface with no or little details of the underlying subsystems so that the normal users can simply use them in their client code easily. The advanced users can of course go to the subsystem level to achieve access to more detailed information.

Another obvious advantage of Facade Design Pattern is that it makes the normal client code independent of the particular implementations of the subsystems as the normal client uses the higher level interface having no details of subsystems. This facilitates any combination of the subsystems to work well for such a client without requiring any client code changes.

How to implement this design pattern? Just think of the higher level interface and extend that interface for different subsystems. Now you are free to have any implementation for the subsystems without being worried about the clients which used the higher level interface.

Flyweight Design Pattern

This design pattern is used in the cases where we have multiple instances with only little lighter (in terms of storage required) differences. In such a case we can have save externally that part (which is typically heavier) of the object state which is similar across the instances and make it shared so that all the instances can point to that. This will help us having only that data in an instance which is prone to change from one instance to another. Such an approach may allow the instances to offload the heavier part of their payload to one shared place in the memory and in turn we'll end up saving the space and the time to create that heavy part redundantly for every instance. Such an approach can be really helpful in the cases where the number of instances are quite high.

How to implement this design pattern? You can create a separate singleton class for the non-changing heavier part and in the actual class you can have a reference to that singleton instance. Not sure how to implement a singleton class? You may like to go through this article - Singleton Implementation in Java >>

Proxy Design Pattern

This design pattern is used to have a simpler object (often called the Proxy object) in place of the more complex object which actually serves the client requests. The simpler object passes the calls to the actual object, maybe after doing some manipulation or transformation. The simpler object makes the life of the client developer easy and s/he doesn't bother about the transformation and other low-level details which the Proxy object handles for them.

The stub and skeleton in RMI do a similar stuff. The client and the server only need to send the raw details to them and they take care of marshalling and unmarshalling.

How to implement this design pattern? Have a simpler higher level class (you can again use the Bridge pattern to design this class) and the method definitions of this class should actually do the required transformation and once the actual parameters are ready then they should call the corresponding methods of the lower level more detailed class which actually does the required stuff.

Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.