Reduce Risk of Change with Effective Class Organization

In a clean system, we organize our classes to reduce change risk. It uses function and class declarations to add commentary to the code.

Short parameter lists and small functions lead to many instance variables used by some of the methods in a class. We have an accumulation of instance variables shared between a few methods. When this happens, it almost always means that at least one other class is trying to get out of the larger class. When classes lose cohesion, split them! When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole. Separate the variables and methods into two or more classes such that the new classes are more cohesive. Breaking large functions into smaller ones causes a proliferation of classes.

Removing duplication is an easy rule to follow, even for novice programmers. The first rule development teams often follow to remember to avoid repeating themselves. The downside of the rule is that, for the most part, it is executed based on visible similarities of the code rather than conceptual ones. The problem with following the rule might lead the team to the wrong abstraction. It takes a lot of effort to deal with the wrong abstraction. It is far cheaper to keep duplication than to have the wrong abstraction. Developers with more experience tend to tolerate more duplication and wait for a better abstraction.

Send messages to access variables, even if you think of them as data. Data very often have behavior that you don’t yet know about. The references are leaky. They escape encapsulation and insinuate themselves throughout the code. When you have data in an array, it’s only a short time before you have references to the array’s structure. They are not DRY. The knowledge about the positions of items in a collection should be distinct. It should be known in one place. Methods with repeating prefixes or suffixes may state the presence of a tortured object trying to be separated. Objects that only serve to forward messages to other objects should be evaluated for their necessity. Hide data from yourself. Doing so protects the code from being affected by unexpected changes.

[¹]: Clean Architecture: A Craftsman’s Guide to Software Structure and Design