<<Clean Code>> Quotes: 10. Classes

Class Organization

Following the standard Java convention, a class should begin with a list of variables. Public static constants, if any, should come first. Then private static variables, followed by private instance variables. These is seldom a good reason to have a public variable.

Public functions should follow the list of variables. We like to put the private utilities called by a public function right after the public function itself.

Encapsulation

If a test in the same package needs to call a function or access a variable, we’ll make it protected or package scope. Loosening encapsulation is always a last resort.

Classes Should Be Small!

The first rule of classes is that they should be small.

With functions we measured size by counting physical lines. With classes we use a different measure. We count responsibilities.

The name of a class should describe what responsibilities it fulfills. In fact, naming is probably the first way of helping determine class size.

For example, class names including weasel words like Processor or Manager or Super often hint at unfortunate aggregation of responsibilities.

The Single Responsibility Principle

The Single Responsibility Principle(SRP) states that a class or module should have one, and only one, reason to change.

Trying to identify responsibilities(reasons to change) often helps us recognize and create better abstractions in our code.

Getting software to work and making software clean are two very different activities.

The problem is that too many of us think that we are done once the program works.

At the same time, many developers fear that a large number of small, single-purpose classes makes it more difficult to understand the bigger picture.

However, a system with many small classes has no more moving parts than a system with a few large classes.

Cohesion

Classes should have a small number of instance variables. In general the more variables a method manipulates the more cohesive that method is to its class.

When cohesion is high, it means that the methods and variables of the class are co-dependent and hang together as a logical whole.

The strategy of keeping functions small and keeping parameter lists short can sometimes lead to proliferation of instance variables that are used by a subset of methods. When this happens, it almost always means that there is at least one other class trying to get out of the larger class. You should try to separate the variables and methods into two or more classes such that the new classes are more cohesive.

Maintaining Cohesion Results in Many Small Classes

Just the act of breaking large functions into smaller functions causes a proliferation of classes.

When classes lose cohesion, split them!

Organizing for Changing

The problem with opening a class is that it introduces risk. Any modifications to the class have the potential of breaking other code in the class. It must be fully retested.

Private method behavior that applies only to a small subset of a class can be a useful heuristic for spotting potential areas for improvement. However, the primary spur for taking action should be system change itself. But as soon as we find ourselves opening up a class, we should consider fixing our design.

We want to structure our systems so that we muck with as little as possible when we update them with new or changed features. In an ideal system, we incorporate new features by extending the system, not by making modifications to existing code.

Isolating from Change

By minimizing coupling in this way, our classes adhere to another class desgin, principle known as the Dependency Inversion Principle(DIP)/ In essence, the DIP says that our classes should depend upon abstractions, not on concrete details.