The Forces of Characterization and Cohesion

Often times the first stage of enlightenment is when an original and revolutionary idea comes to me and grabs my attention. In most of those cases, the second stage of enlightenment is when I realize that I had actually heard that idea from someone else.

Regarding my latest "enlightenment", in the area of class names, I can't remember all of the sources of inspiration that came together but I experienced it while I was reading Kent Beck's book "Implementation Patterns". The book is a collection of principles that promote improved code readability.

While reading about the importance of selecting names for classes, a couple of principles that I had heard before came together into a single picture.

That picture is made up of two forces.

The Force of Characterization

The first is the Force of Characterization. It exists between a class' name and the class' code. If, and only if, the class' name properly characterizes what the class does, the Force of Characterization is in harmony.

For example, if the class' name is Account and the code for the Account class does currency conversion, the name Account is a mis-characterization of the class' code.

The Force of Characterization moves you to to examine the fit between the class' name and what the methods do and, where the fit is bad, it causes you to adjust either the name or what the methods do to bring the Force of Characterization into balance.

The Force of Cohesion

The second is the Force of Cohesion. Cohesion exists in a class' methods to the extent that the class' methods work together for a single purpose.

If some of Account's methods provide account related operations (e.g. deposits, withdrawals), and other methods perform currency conversion, the methods are not cohesive.

The Force of Cohesion moves you to examine the class' methods and how well they work together to a single end. Bringing harmony to the Force of Cohesion is done by moving methods and perhaps data from one class to another. It may also involve splitting up a single method into multiple methods.

Interplay Between the Forces

Where this gets interesting is when these two forces start interacting with each other.

As you change a class' name, you may be changing its purpose. For example, changing the name of a class from CustomerInfo to Account significantly changes the expectations that a user would have for the class' code.

Because the class' methods should be acting towards one purpose (the class' single purpose), changing the name of the class can affect the cohesiveness of the class' methods. The single purpose that the class' methods were working towards before the class was renamed might have been redefined into two or more purposes.

In other words, when you change the name of a class in an attempt to harmonize the Force of Characterization you may temporarily introduce disharmony with respect to the Force of Cohesion. The converse of this is also true.

Sometimes a disharmony in one force can be resolved without introducing disharmony in the other force. However, I imagine these two forces occasionally going through cycles of harmony and disharmony, in and out of phase with one another, until both forces are in harmony, and a stable state has been reached.

Conclusion

1. Changing a class' name can move you to change the class' methods to restore harmony in one of the two forces.
2. A class' name is important when adding features; it helps you answer the question, "Does this method/data member belong in this class?" If you achieve harmony between the two forces, the class name will be a helpful guide as you read and maintain the class' code.
3. Changing a class' name may prompt you to rename methods to be more consistent with the name.
4. A class name that is a good characterization of the class' methods can actually assist you in maintaining the cohesiveness of the class by making un-cohesive code more obvious.
   

Question(s):

1. Are there other forces that interact with class names and cohesion in interesting ways?