Wednesday, February 19, 2014

Keeping clean code principles for esoteric classes...?

Let's face it, most of our classes will never by used by more than a lonely class. If this is the case, it seems that many of the clean code principles are meaningless for those classes... Or are they?

SRP
One principle to consider, is the Single Responsibility Principle. In his book, Principles, Paterens and Practices (PPP), "Uncle Bob" gives the example of the Rectangle class. This class has 2 responsibilities: the first is to provide a mathematical model of the geometry of a rectangle, and the other is to give some GUI services such as drawing it on the screen. Two different applications use this class: GraphicalApplication and ComputationalGeometryApplication. If a change to the GraphicalApplication causes the Rectangle class to change for some reason, the other application, ComputationalGeometryApplication, needs to be rebuilt, retested, and redeployed.
That really sounds bad, but as I stated at the beginning, most of our classes are never being used by more than one class, not to mention more than one application...

High Cohesion
Another principle is the High Cohesion Principle. This principle states that most of a class's members should be in use by most of the functionality it exposes. Usually, classes that violate this principle, expose many functionalities and therefore have many private members that need to be instantiated. When you need to use some functionality of such a class, you must go through a painful instantiation process - you must provide it all the state it needs, even if most of this state is irrelevant to your needs.
And yet again, if a class is only being used by a lonely class, then probably all the functionalities and all the required variables are truly relevant to that lonely class.

Encapsulation
The last principle I would like to consider is encapsulation. In his other book, Clean Code, "Uncle Bob" says about encapsulation:
"There is a reason that we keep our variables private. We don’t want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse. Why, then, do so many programmers automatically add getters and setters to their objects, exposing their private variables as if they were public?"
But if a class of mine is only being used by a lonely class, what's the big deal? If I will ever need to change the type or the implementation of a variable my class exposes, I will only have to change two classes - my class and the class that use it, not such a big deal...

But wait...

Having said all that, I still encourage you to keep those principles for ALL your classes, even for those that are only being used by a lonely class.

It's true, most of your classes will never be in use by more than one class, not to mention more than one application.
And yet, sometime in the future, some of them will! You never know which classes are those; you never know when will they start to be in use in other places; you never know how much are they going to be used.

Conclusion
Therefore, treat each and every class as if it is going to be used by many classes, there is a chance it will...