Monthly Archives: September 2013

Understanding Open/Closed Principle

Open closed principle is an important rule in software design, which we need to follow when designing a software system. It states “A Software code should be open for extension but closed for modification”.

What does that mean? Let’s take a very simple example from day to day life. We all use TV remotes. Say, we have created a very simple software code for remote operations like on/ off, vol increase/ decrease, channel change etc. Now what should be my design considerations

1. Any one should be able to extend the code to add new functionality, for example, for advanced TV’s one should be able to add functionality for subtitle language selection, operator specific options etc.
2. At the same time I need to make sure that no one should be able to alter existing core functionality like vol increase/ decrease, so that it does not break down the functions which are working fine perfectly.

Point 1 is what we say open for extension and point 2 states closed for modification principle. The open/ closed principle helps maintainability of code perfectly, by making sure we do not break what is working fine with flexibility of adding new features at the same time.

Composite Design pattern

When I first tried to understand composite design pattern, I came across this UML explanation

composite_pattern

Image source : wikipedia

To start with, I was not able to make any sense out of this, so I tried to look for simpler example, and came up with this

composite2.

Think of a scenario where we need to support a tree format data structure. Where every node can be composed of more similar nodes, or a leaf node. For example in above scenario, at leaf level we have juniors, to whom no one report. At non-leaf level we have managers, to whom, juniors and other managers report, and these managers themselves report to some senior manager. To help us structure this kind of complex relationship, composite design pattern comes into play.

Proxy Design pattern

Proxy design pattern is one of the simplest design pattern. The name explains it all, we place a proxy class between the client and actual implementation. An example is EJB’s home and remote interface implementation. Or think of a webservice call, where we are trying to fetch Employee details from webservice. Instead of calling the webservice directly we bring in a proxy class, which is called by client and it call’s the actual webservice later. The advantage it gives us is that if the webservice call changes, say url for the call changes or pattern of input/ output xml is modifies, we just need to make change at one place, rather than changing calls at multiple clients.

proxy

Bridge Design pattern

When I first tried to understand Bridge pattern, I got it confused with Adapter pattern and then Abstract Factory pattern. In my defense, these patterns do have features overlapping. But when I got into depth of bridge pattern, the advantages got clear i.e. decouple an abstraction from its implementation so that the two can vary independently.

Bridge pattern allows an abstraction and implementation to change independently whereas an Adapter pattern makes it possible for incompatible classes to work together