OO Design Patterns that can make a difference

Karthik Muthupalaniappan, Wednesday, October 7, 2009 @ 10:53 am

Design patterns. I think they are the one of the most intriguing areas of object oriented application design and development. There are so many out there that can puzzle you each and every time you try to take a crack at them (I can name a few of them that I still can't figure how they are to be used or implemented).  But a thing that most programmers would agree is if used wisely and appropriately, these design patterns can provide really powerful benefits that can enhance one's programming experience and also the software that is being built. There are several patterns I have used/implemented in my projects that I think are awesome. I ll touch upon how I used some of them and why every Object oriented programmer needs to master them.

Factory Method

This must be one of the most commonly used patterns out there. We indeed have used it the most in our projects. The crux of this pattern is essentially delegating the task of creating objects to a method that basically takes in information about what kind of object is to be created etc.  There were a number of instances in the applications we built where there was a base domain object that had a bunch of derived types. In most of these instances, single method/interface that returned the base domain object type but created instances of the appropriate the derived type was used. The benefit? The object creator is decoupled from the users of the objects and makes the code more reusable and maintainable.

Dependency Injection

I m absolutely in love with this design pattern. It is a very effective design approach in my opinion. What it advocates is lazy/runtime injection of object dependencies or modules instead of hard-wiring them.  There are a number of third party dependency injection frameworks like Spring, Object Builder etc that let you implement dependency injection out of the box. A very simple example of how I used this on a recent project : Consider the application needs to talk to a remote service for what ever reason. We also built out a fake service that mocked the real remote service to enable us to test/run the application when the real one was unavailable or being developed. We needed a way for the application to swap dependencies (basically the real service and the fake one) at run time. Spring .NET's dependency injection enabled me to implement this.

Command Pattern

A really powerful design pattern that helped us a great deal in implementing an undo/redo feature  in one of our desktop application projects. The idea is pretty simple. Every operation that you want to be undone/redone is encapsulated in the form of a command object that contains information about the method or delegate that needs to be invoked for that operation, parameters for that method or delegate, the undo method etc. Every time, any such command is executed, it is pushed to an undo stack. If the command needs to be undone, it is simply popped off the stack and the undo method is invoked. There is a redo stack for handling redo operations.

Other patterns that I have used widely are the Singleton, Facade, MVC, Pure MVC and MVP. These are effective in their own different ways.

Related posts:

1. Using Design Patterns
2. Defining RIA Interaction Patterns on time in Flex Agile Development
3. Style Guide tips and Tricks: Finding patterns
4. BRE Patterns III: Collaboration Cop, Part I
5. Anti-patterns in Code: Ubiquitous HashMap

Comments (4)

Software Development

Comments: 4 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Design patterns are useful apart from their specific uses because they cause us to realize that many problems have already been solved, irrespective of language or platform.

   Comment by Mark Wilden, Wednesday, October 7, 2009 @ 11:32 am

2. [...] OO Design Patterns that can make a difference | Pathfinder Development | Software Developers | Blog… [...]

   Pingback by Ennuyer.net » Blog Archive » Rails Reading - Oct 20, 2009, Tuesday, October 20, 2009 @ 12:28 pm

3. 

   Like the article – nice discussion on design patterns…

   Want to throw out a couple of thoughts though… the idea of design patterns caught a lot of traction several years ago – every hiring manager had to ask about singleton, factory, etc.. it seems like it’s tappered off a little…

   The general thinking about design patterns is a little off – they aren’t cogs that you can grab and throw at a problem and *bang* your problem is solved. (This may be a simplification – but I get the impression it’s the general feeling about patterns by many)

   I think a more appropriate analogy would be that they are like musical riffs that a master improvisational musician learns… she learns them not to (necessarily) play the exact riff in a performance – but so that she’ll have a large base of ideas from which to form her own (which will have to be specific to her current context).

   That being said, the power of patterns are greatly underestimated – not in their specific technical application – but in their ability to expand the thinking of the practioner of the Craft.

   Comment by Kyle, Friday, October 23, 2009 @ 9:13 am

4. 

   @Kyle – Welcome your thoughts on Design Patterns. I totally agree with the points you made in your comment. A Design pattern works best when it is applied in the appropriate way to solve an appropriate problem!

   Comment by Karthik, Friday, October 23, 2009 @ 2:06 pm

Leave a comment