"Effective Java" Learning notes (3)

Notes
Four. Classes and Interfaces

12th: Minimize the accessibility of classes and members

In order to better realize the information hiding, reduce the coupling degree of each module, it is necessary to reduce the access ability of class and member as far as possible. One particular key is that the static final domain of the public is almost entirely wrong. The customer can modify such an array of members that it is safe to change to private.

13th: Support for non-mutable classes

The following 5 points are required to make a Class A mutable class:

1. Cannot provide any method that modifies an object

2. To ensure that there is no quilt-like override method, you can achieve this by making this class final

3. So that all the member variables are final

4. Make all member variables private

5. Guaranteed mutex access for any variable component

The advantages of making a Class A mutable class:

1. Non-variable classes are usually simpler, hehe, it's obvious that he has only one state

2. Non-mutable classes are usually thread-safe

3. Non-mutable classes provide many artifacts for other objects

4. The biggest disadvantage of a non-volatile class is that for each different value (or state), a separate object is required, and in some cases you need to create a very large number of objects that have a significant performance impact

Still, trying to make every class A mutable class should be your goal.



14th: Compound is better than inheritance

Looking at the introduction to object-oriented programming yesterday, it is said that "subclasses" and "subtypes" are different, the substitution principle is only appropriate for subtype relationships, and the general programming language only takes into account the subclass relationship, which shows that the new class is inherited from the parent class, whereas the subtype emphasizes that the new class has the same behavior as the parent class (not necessarily inheritance). So, when should you use inheritance? That is, when conforming to a subtype relationship, or, generally speaking, "is a" relationship, you must ensure that the behavior of the new class is exactly the same as the parent class!!! In any use of the parent class, the new class should behave the same way.

Inheritance is one of the most important concepts of OOP, but inheritance also destroys encapsulation, and the implementation of subclasses depends on the implementation details of the parent class. So, in addition to the above mentioned situation, you should try to replace the inheritance with the compound. (In the Overwrite Equals () method also refers to this) otherwise all belong to the abuse of inheritance, the abuse of technology has become commonplace.

15th: either specifically designed to use inheritance and give documentation instructions, or prohibit inheritance

This is the same point as the above. If you want to use inheritance, do the design, do not call any mutable methods in the constructor, Clone (), Readsolve () method, and write a detailed document description. In fact, the best situation, or not to use good!



16th: interfaces are better than abstract classes

An interface is the best way to define a type with multiple implementations, and it is clear that each concrete class implements the interface differently. If the ease of evolution is more important than flexibility, you should use abstract classes. For example, if you add a method to an abstract class, any subclass that implements the abstract class automatically has this method, and the interface does not, and all publicly-owned interfaces are designed with great care and guaranteed to do nothing to make changes. When using interfaces, it is common to design an abstract class as a "skeleton", which should be as small as possible and retain only the most basic functionality.

17th: interfaces are only used to implement types

You implement an interface, which means that the class is the type of the interface. In the application we often see the definition of static public constants in the interface, which is actually a misuse of the interface (Khan, I am a typical of this error), such as

public interface constants{

public int one=1;

......

This form is completely wrong and should be replaced with a class that cannot produce an instance

public class constants{

Private COnstants () {}//constructor is proprietary

pulic static final int one=1;

......

}

18th: Priority should be given to static internal classes

Non-static classes are always associated with instances of external classes, and you should try to use static inner classes as much as possible.