Saturday, June 21, 2008

Abstract Factory Pattern

Along with Vidula, I had been assigned to do a series of tech talks on design patterns. Our initial objective is the cover the eight software design patterns that has been deemed to be most important. I will cover four of these patterns and hope to have the slides on the blog after I complete the tech talks. In the series of these tech talks the first was on abstract factory pattern and here I have attached the slide along with this blog.

At the end of the presentation some interesting aspects and perspectives on this was discussed.

Error opps "errors"

First a staring error in the diagram was pointed out by Thilina, where one of the concrete factories was not shown to have been extended from the abstract factory, my apologies for not noticing that!

Any how I will not accept the other error that was pointed out, where it was said that piece of code was misleading in the main method, since I have not handled any other cases(when its not EU or Canada). Unfortunately I feel that code that I write on slide for a presentation is not for the purpose of code review, but is intended to be coherent with my overall objective of getting the usage of the abstract factory pattern to the audience. Further more I had to consider the space that I have on each slide to play around with , probably if my overall objective was to explain the usage of the if else statement to a group of amateur programmers then I would have accepted that I had made a glaring error in not handling the other case and logging it J

Usage of the abstract factory pattern in a spring application

Spring being service oriented architecture enables the injection of the objects which implements the defined service interfaces. It just does the job of the abstract factory pattern and in the words of Harsha it is almost 80% of the abstract factory pattern, any how a purist could argue that it’s not an abstract factory as it does not comply with all the requirements of being an abstract factory.

Switching between different kinds of message sending implementations

A common scenario that we face is having various message sending mechanisms to choose from and is required to switch as and when required for example from email to sms or ussdc …. The question was this if abstract factory was appropriate for this purpose? At the outset it might sound to be appropriate, any how if considered with respect to the other available options it was suggested that the strategy pattern might be more appropriate.

A wait the next design pattern slides!

No comments: