The God object (patterns) [2]

In the previous post I was at a point where the baby was feeding, sleeping and most importantly making sure we spend money on nappies. In this post I attempt to extend my initial design.

So far my TheSpecialOne class looked like below:

A week went pass and after many hours of sleepless nights we realised that the baby was constantly hungry. Being responsible parents we kept on breast feeding, but it was time for the magic formula milk.

Our requirements were very simple. We wanted to be able to breast feed and swap to formula milk to top up. We wanted make this change without having to disturb the baby too much (or without him knowing).

If you take a step back, we see that feeding is an activity and only the method used for feeding is what is changing. So in reality we should be able to swap between different implementations (of feeding methods) without changing the abstraction. We would need the flexibility to alter the feeding process independent of the method used. Sounds familiar? What I am describing here is the Bridge pattern.

I have done some fundamental changes to my initial design. I introduced a new interface called IFeedStyle. This is the abstraction I will use to introduce different methods of feeding (e.g. bottle, spoon feed etc).
However I know that as he grows, we will need to be flexible. Consider the following code.

The key aspect here is that the "Start()" method is abstract. This way I can create as many derived classed as I want. As the baby grows his eating habits will change. While he is a baby, he may only take milk, but when he becomes a toddler some solid food. But while having solid food he may like to play with some toys but drink milk using a bottle. The idea is simple, based on different strategies, we can decide how to feed. For the moment we will only have a baby specific implementation of this abstract class.

The above abstract class must be integrated to the Person class. The following is the modified Person class.

I think you should see the advantage of using the Bridge pattern. The actual task of feeding does not change, only the implementation that meets the FeedableBase class. We can provide different implementation without modifying the Person class. Now the IFeedingStyle and FeedableBase can change independently.

All set, the calling code looks like this:

More to the point, the output looks like this.

Enough fun and back to real work!! (code is here)

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.)