The Adapter Pattern

Note: The word client and caller are used interchangeably in this document which both refer to the class/method which calls the method of another class.

Note: CLICK ON IMAGE TO ENLARGE IT.

About : Being adaptive is at the core of any human activity which requires a person to become conversant to the changing environment. And surprisingly OOP also comes under the same category!!. Many times it happens that the class or interface we are using is not,for any particular reason , compliant with the one which client expects. In such cases the adapter pattern can come to our rescue. It is recommended that you use this pattern wisely in order to avoid unexpected results.

Definition :converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interface.

When to use it: We can use this pattern when, due to compatibility issues the caller does not identify our interface as the one expected by it. Let's say, we have a library provided by our client which expects some interface and your company has ,in past, developed some libraries. Now, in order for our libraries to be used by client-provided libraries they must be compatible. What this pattern does is they MAKE the client SEEM that it is compatible.

How to use it : All we need to do is, create a concrete class which implements the interface which client expects and, delegate the request to the concrete class which implements the interface, which we need to function in response.

Example : The diagram 1.1 illustrates how the request came for a target interface gets delegated to another interface. Here, the client only “looks” at the interface being implemented.



To make the pattern more clear, let's understand it with a real world(confined to Java) example.

We have nice collection interfaces, java.util.Enumeration and java.util.Iterator. Both having methods to iterate through the objects of any of the java.util.Collection subclasses. Now,through the use of Adapter Pattern, we can create an adapter which makes client seem, if not actually make, the objects of java.util.Iterator compatible with objects of java.util.Enumeration. Diagram 1.2 below shows the class diagram for the same.






Conclusion : To summarize, when the “type” expected by the client differs from the one we have, use this pattern. To make components more adaptive,which might not have been otherwise , we can use this pattern to suit to our need.


Any suggestions or queries are welcomed.

The strategy Pattern

Note: This design pattern and all those which are posted on this blog are written by me after reading the book "Head First Design Patterns" so the definition and understanding of ideas will be from that book. The purpose is to give a concise explanation of the design patterns.For more detailed explanation please refer to the book

Note: CLICK ON THE IMAGE TO ENLARGE IT.

About : A beautiful design pattern which demonstrates how we can ,through the use of composition( HAS-A relation) over inheritance( IS-A relation) , reduce the harmful effects of change in code and make the design more flexible.
We can change behavior at runtime and change the code without affecting the client, which uses them.

Definition : The strategy Pattern defines a family of algorithms, encapsulates each one,and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

When to use it: when we have common type of behavior in our various subclasses and they may change in future and if the subclasses are too many then we need to change the the behavior by editing each and every class where change is needed. This happens because our implementation is “locked” inside our subclasses and thus whenever change is required we need to change each and every subclass.

How to use it : Identify aspects of our application that vary and separate them from what stays the same. So, by making a loose coupled design through the interface we make the caller unaware of the implementation and thus implementation can change without touching code at the caller side.

Example : Lets say we have a class which has two behaviors one is common to both the subclasses and other is new behavior which is applicable to one subclass which not to the other. So in this case if we depend on inheritance then we have to give empty implementation of the new behavior in the SubClass2. This design is not loosely coupled, implementation is locked inside subclasses. So in case we have to change the new behavior in any subclasses then we need to make changes there. If there were 20 behaviors and 100 subclasses then the changes would be felt worst.



So we'll try to make our design more flexible by introducing interface and removing the things that changes from subclasses and separating that into interface.This change seems convincing as the behavior is made optional through use of interface. The classes which needs this behavior will implement the interface. But still the change in the subclasses will need us to alter the code in the subclasses. Thus ,this design still depends on the implementation given by the subclasses who implement the interface.

Lets improve the design a little bit. This time we'll separate the implementation not through inheritance but through composition.


Now the implementation is separated from the place where it was used. So, any subclass can use any of the XYZBehavior implementation through the reference it holds of XYZable interface. And so the changes made in XYZBehavior implementation does not affect the caller(i.e. Any subclass ).This makes design more flexible.


Conclusion : Separate the functionalities of your application that changes from what stays the same. And prefer to use composition over inheritance when you need a flexible design because interface gives dynamic allocation of objects and loose coupling while inheritance gives implementation which is static inside the class and makes code hard to manage when exposed to changes.

Any suggestions or queries are welcomed.