four. Category and interface
Article 12: Make the accessibility of the class and members
In order to better implement information hidden, reduce the coupling of each module, which can reduce the access capabilities of classes and members as much as possible. There is a little particularly key, that is, the public static Final field is almost all wrong. Customers can modify the array of members and should be changed to private.
Article 13: Support non-variable class
Make a class that is non-variable class to do the following 5 points:
1. No way to modify the object
2. Ensure that there is no method that can be covered by subclasses, you can reach this class as Final.
3. Make all members variables all Final
4. Make all members variables are private
5. Guaranteed to mutually exclusive access to any variable components
Make a class becomes a non-variable class:
1. Non-variable classes are usually simple, huh, huh, this is obvious, he only has a state
2. Non-variable classes are usually threaded
3. Non-variable classes provide a lot of components for other objects
4. The biggest disadvantage of non-variable classes is to require a separate object for each different value (or status), in some cases you need to create a lot of objects, high performance
Despite this, try to make every class a non-variable class should be the goal you pursue.
Article 14: Composite is better than inheritance
Yesterday, I saw "Object-Oriented Programming", mentioning "subclasses" and "subtype" are different, the replacement principle is only suitable for sub-type relationship, and general programming language is only considered by sub-class relationships, and the subclasses have explained new The class is inheriting from the parent class, while the child type emphasizes that the new class has the same behavior (not necessarily inherited). So, when should I use inheritance? That is when the child is related, or the "Is A" relationship that is generally said, you must ensure that the actions of new categories are exactly the same as the parent class! ! ! In any case where the parent class is used, the new class should behave the same behavior.
Inheritance is one of the most important concepts OOP, but inherits also destroyed "encapsulation", the realization of subclasses depends on the implementation details of the parent class. Therefore, in addition to the above mentioned, you should use a compound replacement inheritance. (In overwriting the equals () method, this is also mentioned) otherwise the abuse of inheritance, the abuse of technology is not uncommon.
Article 15: Either a special design to use inheritance, and give document description, or prohibit inheritance
This is the same as the above emphasis. If you want to use inheritance, please design, do not call any variable method in the constructor, Clone (), ReadSolve () method, and write detailed documentation. In fact, the best situation is still not used!
Article 16: Interface is better than abstract class
The interface is the best way to define the type with multiple implementations, which is obvious, and each specific class is different. If the evolution is more important than flexibility, you should use an abstract class. For example, you have to add a method to an abstract class. Any subclass of this abstraction is automatically has this method, and the interface cannot be, all public interface is very cautious and guarantees that do not make changes. When using the interface, a abstract class is generally designed as a "skeleton", which should be as small as possible, only the most basic functionality is retained.
Article 17: The interface is only used for implementation types.
You implemented an interface, representing this class is the type of the interface. In the application, we often see the static public constants in the interface, which is actually misuse of the interface (sweating, I am a typical typical), such as
Public interface constants {
Public int one = 1; ......
} This form is completely wrong, should be used instead of a class that cannot generate an instance
Public class constants {
Private constants ()} // constructor is private
Pulic static final int one = 1;
......
}
Article 18: Should be preferred to consider static internal classes
Non-static classes are always associated with examples of external classes, should try to use static internal classes.
