Abstract Factory! why, when and how?

It’s almost close to some 18 years since the GOF came up with a book on design principles. The intent was to capture the reusable aspect of design patterns and appreciate the class of problems these design pattern address. One can assume that by now the whole fraternity of developers and designers across all the various technology domain should have mastered these design patterns, if not all then at least some common ones. The irony is we are still away from that. The very question which comes to mind is, WHY? In this blog I am not intending to provide the solution as to how one should learn design patterns. My intention is to reflect upon why, what and how of design patterns. The motivation is teach myself.

Oh the Abstract Factory!…

I find it a little awkward to use “Abstract Factory” when in real world every factory is for real and produces real products. It is a little tough to imagine an abstract product coming out of an abstract factory. This very abstract product is directly consumable adds to my uneasiness. Too much abstraction but this is what I think the objective is. Create reusable abstract patterns which can fit most of the situation.

Example/Scenario

I live in a place where it rains in the rainy season, snows in winter and hot and sunny in summers. I need different kind of cloths to protect my self from the elements. To do so I go to the store near my house and ask for clothing/item to to protect my self. The store keeper give me the appropriate item as per the environment and depth of my pocket. The items he gives me are of same level of quality and price range. Since he is aware of my standards its easy for him to do so. But when a rich guy from across the street comes up with the same requirements he gets an expensive, branded item. One noticeable thing is all the items he gives to me complement each other in term quality, standard, cost. One can say they go with each other. Same is the case with the items this rich guy gets.

So by looking at above scenario, I now appreciate the efficiency of the shop keeper. I can replace this shopkeeper with and Abstract Shop. The items we get with abstract items and me and the rich as perspective clients. All we need is our product/item suiting to our need.

Now I can easily see my self considering an online store which provides a set of services to its numerous clients. Each client belongs to either of the three group. When a premium group user opens up the site he gets great UI, highly customised advertisement pane,  more options in the menus etc. These same set of features are presented to gold user but the functionality in the menu is less, advertisements are mostly relevent. slightly less agronomic UI. Lastly my kind of user, a ‘free group’ users, I am just served enough so that I do not get offended. The UI is bare minimum, advertisements are way off track so much so that I do not know what comes in it, lastly the menu has only log out.

If I get a chance to build something like this website I would definitely consider Abstract Factory Pattern.

Abstract Products : Advertisement Pane, Menu, UI painter.

Abstract Factory : Web Store User Experience

Concreate Factory: Premium User Experience, Gold User Experience, General User Experience.

no “new” operator why?

Why the use of “new” is risky?

As a programer with a vision to accomplish the functional code we do not consider asking the above question often. Some times I wonder is it really so risky to use “new”. If so then what makes it risky. What are the impacts of using “new”.

• Why we use new?

Whenever “new” is used, we are instantiating an object of some type. Normally this type is some class which needs to be imported. If this class is undergoing changes, especially in its constructor over the development cycle then we have to keep changing and recompiling the  classes which are using it. If the user/importers of this class happens to be the clients/consumers then the cost of maintenance and testing escalates. Writing unit test becomes difficult and eventually descoped. If we happen to be using some logic while instantiating these classes then the complexity keeps increasing. A simple “if else” which looks innocuous becomes complex. A removal of one “if else”/switch reduces the complexity by some appreciable margine.

The approach taken could be in these kind of situation.

1. Use Interfaces as the mutual agreement between layers. or classes.
2. Using interface does not mean that their purpose is for only referencing the implementer instance.
3. Consider a class to be open for extension and close for modification. More so if this is the outside the module/layer.
4. Try to break down the functionality in layers. Confirm that changes in one layer’s internal logic does not trigger changes in the other layers which directly or indirectly depend upon this layer.
5. If there are so many checks then where should we instantiate the objects to concrete classes?
6. Do the basic analysis to gauge the areas where the application will see enhancements. Keep this in mind while designing and coding.
7. Use interfaces to get protection from change.
8. Get a interfaced reference to object via calling a function exposed by a layer/service.