Travel: Masingudi, India

It was a pending farewell treat to my friends in Honeywell that took the form of travel to Masingudi. We could not have chosen a better time, a year had gone by and a new year 2011 was at the door step. And for the same reason it was hard to get bookings but luckily we got to book a 3-bed room in NestInn Masingudi. The earlier plan was to travel to Masingudi from Bangalore in one shot on Friday evening but then the thought of sacrificing one of my big time hobby of sleeping was too much, it was much better to break the travel in Mysore, so we booked a 3-bed room in ShantiNivas hotel in Mysore through internet.

Finally, the day arrived and we started on our travel at 4.00 p.m on 30^th Dec evening but thanks to Bangalore traffic and last minute fixing of the indicator lights we left Bangalore at 6.20 p.m. Cruising towards Mysore in my Dad’s car we ultimately reached Mysore at 9.30 p.m and after some searching through the narrow alleys of Mysore we ultimately found our hotel and to our surprise it was more of a hostel than a hotel. No wonder why we got the booking when no other hotel had rooms available. Well, it was a matter of one night so why to crib.

Deva's skills with his SLR on the way to Mysore

New morning and here it was the last one of the year 2010, we started early towards Masingudi while it was still a little misty and cold. The road was not very smooth but we were lucky that there weren’t too many pot holes.

After a 1.5 hrs drive we entered into scenic Bandipur National Park and were instantly greeted with a group of deer’s. 

Greeted by deers on arrival at Bandipur

 The calmness, freshness of the air and the vastness of the forest had an amazing pull on the psyche that instead of driving fast on that empty stretch we travelled slowly to be with the nature for a longer period. The calmness of the jungle only being shattered once in a while by Patil's shouting thearpy - By the way that's Patil's way of releasing his pent up energy. And probably that was his way to communicate to the other jungle inhabitant's of his arrival but certainly it helped me to stop honking once in a while.

The three musketeers : from Left Patil, Me and Deva

By noon we had reached the NestInn in Masingudi, and without wasting much of time we headed for our water sports at the creek near by, some people found it to be a good place to meditate while others found it good for some drinks.

Two ways of reaching ecstasy

Poor Design – Excessive inheritance

Very often while developing the object oriented systems we have the base master class which has most of the common functionalities like a super dad who can do everything and all its offsprings (child classes) inherit this functionality.

But sometimes just like in real world as the offspring specialize and differentiate themselves from the super dad and develop there own personality there are situation wherein a derived offspring shouldn’t have the functionality but still has the functionality.

I believe a good object oriented system is always closer to the real world and this is where I favor composition over inheritance, a system where each offspring develop there distinct personality by attaining different skills basically the offspring inherit the common features but attain the different skills(functionalites) by composition.

Poor Designs - Using Managers extensively.

I recently had the opportunity to work on a project which used the DSL to design object model and T4 to generate code, using the object data base as data store. And for some reason the team had decided to go for an anemic object model which meant all the business logic needed to be accommodated in the Managers. As a result there were a bunch of managers which enclosed a set of functionality and exposed it through WCF service to client.


A closer look at the whole scheme of things could easily reveal design flaws which have the potential to turn maintenance into nightmare. 

Issues

The design breaks some of the object oriented design principles:

1. SRP – Single Responsibility Principle – A class should have only one reason to change.

I believe object oriented programming models the real life objects where an object not only has data but also knows how best it can do an operation on that data. The managers should be the façade to the functionality provided by the underlying object model. However, instead of delegating the action to an object, the managers are doing all the logic and the objects are used to contain only the data. The Manager classes should be similar to our Managers who know their resources capability (underlying object model) and provide a range of functionality to the outer world by breaking the jobs into smaller pieces (object methods) and delegating them to the resources (objects) who know how best it could be done.

2. The design leads to a big class which has all the functionality where the modification of the class may require frequent merging resolution while checking-in. As every one is working on that same big class.
3. All the automated unit test cases and manual/integration test cases related to the manager needs to be executed to verify that code changes didn’t have any side-effects. Note you would need to run the test cases for even unrelated code just because that code also exists in that same class.
4. It appears to be procedural programming with all objects having the data and the logic contained in the functions of a big class.

Resolution:

Using an anemic model is not true object oriented programming, its always better to have the functionality encapsulated in the object model. However if for some reasons the anemic model is required then it would be better to have another layer of wrapper objects which could encapsulate the functionality.