Commonality and individuality
According to the principle of object-oriented, a class is an abstraction of an object, that is, a class is a series of objects with both generality and individuality, and the properties and methods of the class represent the generality of all objects belonging to the class, each object instance of the class can have different attribute values, which reflects the individuality of each object.
the granularity of inheritance
For an inheritance tree, the hierarchy of inheritance should be refined to what extent is appropriate?
- First, the strength of integration must be determined based on requirements, and if a certain commonality of the extracted object is not helpful to the problem we are solving, or if there is little help, there is no need to extract that commonality and increase the complexity of the inheritance.
- Second, some of the commonality of objects is more appropriate for attributes than for new base classes and derived classes, such as the CPU's first-level cache and the two-level cache, which is simply a quantitative value, and is very convenient to express with an attribute
- Finally, to understand that the use of classes and objects to simulate the real world is a means rather than a goal, not to extract classes to extract classes, our ultimate goal is to maximize the implementation of code reuse, improve the quality of software, so if not to the purpose of reusing code, there is no need to extract new classes
Granularity of aggregation:
In the UML language, the aggregation relationship refers to the relationship between the whole and the part, and the principle of the granularity of the processing aggregation is the same as the principle of handling the inheritance granularity, the simulation world is only a means rather than a goal, and the ultimate goal is to improve the code structure and improve the reusability of the code.
a design that exists purely for code reuse:
In many practical software designs, many designs exist purely for code reuse, meaning that some of the classes in the design do not work with real objects and relationships in the English real world, but the existence of these classes can help to improve the reusability of code and reduce the duplication of code.
The method of reconstructing the class;
- Refinement classes: In the iterative process, you might add properties and methods to the same class continuously, and when the class gets bigger, his responsibilities are not very clear. We can separate some of the properties and methods to form new classes, so that two classes have high cohesion. That is, if the work of a class should have two classes to complete, you must create a new class and move the related properties and methods into the new class, so that the resulting new and old classes are usually joined together in an aggregate relationship
- Inline the class: in the process of refining the class, it is possible to cause some classes to be too small, to blame too little, when we can move the class's properties and methods to other classes, and then delete the class, then the reverse process of extracting the class
- Replace type code with a class: if there is a code in a class that expresses a specific object (type code) that affects the behavior of the class and may cause the branch statements associated with that type to appear frequently in the program, we should create a new derived class and use polymorphism instead of his
- Refinement subclasses: Sometimes, some properties in a class only make sense for some instances of the object, which means that the class's plan is not perfect, and we can also extract these attributes separately to form a derived class of that class
- Refining superclass: If two classes have the same properties and methods, there must be some code in the two classes that is duplicated, and in order to eliminate the bad taste of duplicate code, you can create a common base class of two classes. Move duplicate properties and methods into the base class
- Folding the Inheritance system: in the iterative and refactoring process, it is possible to find that a base class and its derived classes are very similar, only a few differences, at this point, you can combine the two classes, with attributes to express the difference between the two
Object-oriented design: Commonality vs personality-------granularity and aggregation granularity of inheritance and refactoring of classes
