Tag Archives: Design Patterns

Composite Pattern

I recently gave a presentation on Composite Pattern. I had used this pattern earlier in my life without knowing that its name is ‘Composite Pattern’. Learning what you have already implemented becomes easy and I believe that you absorb more out of it.

I referred Gang of Four and Head First Design Pattern books for preparing the presentation. Head First has a very good explanation of using Iterator Pattern with the Composite Pattern and Gang of Four cover mostly most of the issues you can come across while implementing this pattern. I also developed code to demonstrate the usage of the pattern. Sometimes reading code gives more information as compared to the text.

I am sharing the presentation we made. If you have any questions then leave me a comment and I will answer it.

Link to Download Presentation: Composite Pattern

Leave a comment

Posted by on September 30, 2011 in Uncategorized



Strategy Pattern

Strategy pattern defines a family of algorithm which can be used to give desired behaviors to the Objects dynamically.
Objects which can have different behaviors in their life time are harder to manage and it is difficult to use only inheritance to solve the purpose of code-reuse.  So here composition seems to be a better candidate which can ease this situation.

Implementing Strategy Pattern and following the practice of Programming to Interfaces make things flexible enough. Behaviors can be added or changed at runtime. Algorithms/Behaviors can be added to its Family at any time and so does adding behavior to the Object is as easy as calling a setter and passing the new Behaviors Object reference.

To demonstrate this lets consider the following figure.

Here in this figure Vehicle class can have the functionality of start by any means like StartByKick or StartByBattery. These behaviors can be added to any class/subclass of Vehicle. Programming to Interfaces gives the flexibility of even extending and using the family of StartBehaviors.

The most apparent drawback of this Design Pattern is that the Behavior Classes which can be termed as Family Of Algorithms are not in adherence of OOPS. They do not represent a fully qualified Object with its properties and methods. Here the Object/Class is only to have  some specific implementation of Algorithm.

Leave a comment

Posted by on April 1, 2010 in Design Patterns