The God object (discovery) [1]

In Software Engineering the God object this refers to an object that every other object depends on. I am sure simple search on the internet will yield dozens of articles describing the pros-n-cons of using a God object.

Me and my wife welcomed our son few weeks ago and I was immensely busy. It is only today that I managed to find few hours to myself to write this note. When it comes to baby stuff, I think whatever the literature that is available in the market is only half the story (or may be less). Having a child changes everything. This ever-hungry machine will forever change your life and mostly in a good way. Yes, you will loose few hours of sleep here and there but I think its absolutely worth it. The joy and happiness that this new member brings to your small family is priceless. Enough talk.... :-)

The God object is like a baby. We know its there, but for an application point of view its a big black box. The God object can do everything, (e,g write to database, file system, resolve dependencies etc). For a development team that is mature, understanding what the God object is not that difficult. However for a new member its similar to becoming a father/mother for the first time. You just know its there, but just do not know how to use it!

So what do I know about the Baby (God) object. The only thing that I knew at the beginning was it derived from a very generic class Person. Thanks to to modern wonders of science and technology we found out the gender of the baby. Therefore we knew its a Person and had a property called Gender which was set to to Male. So my abstract world looked like this.

After the baby was born I soon realise that this God object has a very simple and effective behavior. Crying. I have to say is very effective and the best way to model this behavior was to implement ICanCry interface. Crying can sometimes be a Big thing! especially for a new born. My object model was evolving.  

My son is very special to me, therefore I did not hesitate to make a brand new instance of this Person. We cannot create an instance of a Abstract class, however we can derive from it. I called this specialisation TheSpecialOne.

You might wonder why I decided Abstract the "Cry()" method as above. The reason is quite simple. Each baby cries differently. Some can be very loud but others are not. Therefore I decided my son can decide how best to cry :-). 

This does not look right, don't you agree? Well, every person should have a gender. We need to ensure that this is a required property. The best way to make sure that the Gender is populated is to have the Person class to contain a constructor that takes in the gender as a parameter.

We were starting to forget the most important piece of the puzzle. The Name. There is no doubt that a person should have a name, therefore I introduced the new Name property to the Person class.

Few hours after the baby was born he was ready to feed. As this is a fundamental behavior of a person, I thought of introducing this behavior to the Person class for the moment.

It did not take even few more hours to realise another fundamental behaviors. These were "poo" and "sleep". So I modeled this in to my glorified Person class. 

One thing I did do was to implement "Poo" in the base class itself. Whatever we take has to come out at some point. Therefore I did not really see the point of having a specialisation of "Poo" in my TheSpecialOne class.

So far my son is feeding, sleeping, crying and can poo. (Code is here.)