Snowing Code

Personal notes on software development


Composition vs Inheritance vs High Cohesion

(Publish date: 25/04/2010)

A couple of months ago Chad Myers has posted a great post about the importance of using composition and its advantages over inheritance, in which he makes the case for (amongst others) using IoC container in order to minimize inheritance. He ends the post by saying that :

Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters.

Now, the point I wanted to make is that the key to his post, or in other words to clean, small, easily maintained classes that would respect the single responsibility principle, would be found in the sentence just before the highlighted one- ”object composition [...] helps you keep each class encapsulated”.

The project that we’re currently working on uses StructureMap as IoC container (and just for the record, not a day passes without me saying thanks to Jebus and Jeremy for providing us with StructureMap! ). The orders we’ve received from our project manager at the beginning of the project were very clear: each controller should depend on one service only, while services should remain as small as possible. Soon after our project manager was high-jacked to other projects and we were left on our own. Now, even though I understood very well what he meant by “don’t let your service to grow too big”, and remembered him showing me a service class from his preceding project that was more than a thousand lines long, I still struggle up to this day with services I’ve written myself, trying to find the time to refactor/split them into several different services. So where did it all go wrong?

So, yes, object composition indeed helps you, but it won’t do the job for you obviously. Personally, from what my experience have taught me, I could have really got it right the first time had I understood and grasped the idea of high cohesion. The first example that pops to my mind is a controller I’ve written for the creation of one of our bigger entities. I used composition when I’ve written the entity itself, seeing that it was too big and that it demanded a wizard-like user interface, so that each wizard step was encapsulated into an entity. However, I have failed to split the service into several ones, thus ended up little by little with an ever growing, massive class with far too many dependencies. Thing is, in this case the separation was needed in every layer,  so that my controller and the service dragged one another- since I had one controller only to take care of the entire creation process, and the controller was dependant on one service only, I found myself with a service class that is a nightmare to maintain.

From Wikipedia:

cohesion is a measure of how strongly-related or focused the responsibilities of a single module are. [...] If the methods that serve the given class tend to be similar in many aspects, then the class is said to have high cohesion. In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.

Cohesion is decreased if:[...]

  • Methods carry out many varied activities

Clearly, the whole creation process of this complex entity wasn’t supposed to  be contained in a sole controller/service.

Failing to understand all that, I managed to bloat one of the layers of our application, while using DI. Some of our services more than 15 dependencies in their constructors!

On top of that, using MSMVC’s magic strings everywhere made the refactoring and splitting of controllers (and thus of services) an extremely difficult task. This is a case where the advantage of FubuMVC over MSMVC is very clear :)

blog comments powered by Disqus