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.There 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.This follows the stepdown rule and helps the program read like a newspaper article.
Encapsulation
We like to keep our variables and utility functions private,but we're not fanatic about it.Sometimes we need to make a variable or utility function protected so that it can be accessed by a test.For us, tests rule.If a test in the same package needs to call a function or access a variable, we'll make it protected or package scope.However, we'll first look for a way to maintain privacy.Loosening encapsulation is always a last resort.
Classes should be small
The first rule of classes is that they should be small.The second rule of classes is that they should be smaller than that.As the functions, smaller is the primary rule when it comes to designing classes.
With function 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.If we cannot derive a concise name for a class, then it's likely too large.The more ambiguous the class name, the more likely it has too manu responsibilities.We should also be able to write a brief description of the class in about 25 words without using the words if, and, or , but.
The Single Responsibility Principle
SRP states that a class or module should have one, and only one, reason to change.This principle gives us both a definition of responsibility and a guidelines for class size.Classes should have one responsibility -- one reason to change.
Cohesion
Classes should have a small number of instance variables.Each of the methods of a class should manipulate one or more those variables.In general the more variables a method manipulates the more cohesive that method is to its class.A class in which each variable is used by each method is maximally cohesive.
In general it is neither advisable nor possible to create such maximally cohesive classes; on the other hand, we would like cohesion to be high.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 a 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 such that the new classes are more cohesive.
Maintaining Cohesion Results in Many Small Classes
Breaking a large function into many smaller functions often gives us the opportunity to split several smaller classes out as well.This gives our program a much better organization and a more transparent structure.
Organizing for Change
For most systems, change is continual.Every change subjects us to the risk that the remainder of the system no longer works as intended.In a clean system we organize our classes so as to reduce the risk of change.
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 talking action should be system change itself.
Isolating from Change
Needs will change, therefore code will change. We learned in OO 101 that there are concrete classes, which contains implementation details(code), and abstract class, which represent concepts only.A client class depending upon concrete details is at risk when those details change.We can introduce interfaces and abstract classes to help isolate the impact of those details.
Dependencies upon concrete details create challenges for testing our system.Dependencies upon concrete details create challenges for testing our system.DIP says that our classes should depend upon abstractions, not on concrete details.