Following the standard Java convention.
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.
The first rule of classes is that they should be small. The second rule of classes is that they should be smaller than that.
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 many responsibilities. For example, class names including weasel words like
Superoften hint at unfortunate aggregation of 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,” or “but.”
God class—or, alternatively, god object—is an anti-pattern that consists of having a class that does too much. A god class is usually a huge class that concentrates a lot of responsibilities, controls and oversees many different objects, and effectively does everything in the application.
There are several problems with God Class:
- Violate SOLID
- Make Your Code Fragile
- Harm Testability
- Harm Performance
- Make the Code Harder to Understand
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 guidelines for class size. Classes should have one responsibility—one reason to change.
Classes should be cohesive — cohesion results in many small classes.
Classes should have a small number of instance variables. The more variables a method manipulates the more cohesive that method is to its class. Try to separate the variables and methods into many small classes such that the classes are more cohesive.
There are 2 types of Cohesions: Low Cohesion and High Cohesion.