Understanding composite objects and class inheritance

　　

1. Conceptual analysis

• inheritance:"Inheritance" is a concept in object-oriented programming.

The single principle of responsibility for object-oriented programming (Spr-single Responsibility Principle) Specifies that an object can have only one responsibility. As far as a class is concerned, there should be only one cause for it to change. Why should different responsibilities be assigned to different classes? Because each responsibility is an axis of change, when demand changes, the change is reflected as the class's responsibilities change. If a class takes on more than one duty, it means that there are multiple reasons for it to change. If a class takes on too much responsibility, it is tantamount to coupling those responsibilities together. A change in one's responsibilities may inhibit the ability of the class to perform other duties, and such coupling can lead to fragile designs. When changes occur, the design is subjected to unexpected damage.

The core implication of this principle is that a class should have and have only one responsibility . With regard to the meaning of duties, object-oriented master Robert.c.martin has a well-known definition: The responsibility of a class is the cause of the change, and if a class has more than one responsibility, there will be several different reasons for that kind of change. In fact, coupling a number of unrelated responsibilities will reduce the cohesion of this class.

For example we now have two classes, D and C. Objects of Class D can use methods or properties that are only valid for Class C objects, which make these methods and properties as defined by D. At this point, C is the parent class of D, and D is the subclass of C. Because the inner details of the parent class are fully visible to the child class during the inheritance process, the inherited code reuse is called "White-box Code Reuse" (White-box reuse).

Therefore, when you create a new object in a way that inherits from another object, the goal should be to make the new object more specific than the original object.

• Object Composition (Composition object): Multiple elements are treated as an object and need to be combined.

An object can use an object as its own member variable, and if an object is created with such a class, then there will be other objects in the object, that is, the object will have other objects as part of itself (this is often said Has-a), or that the object is composed of several objects.

The combination of objects creates new, more complex functions by assembling (combining) existing objects, and the code reuse in this way is called "Black-Box Code Reuse" (Black-box reuse) because the internal details of the objects are not externally visible. Object combinations require that the objects being combined have well-defined interfaces.

Example:

<?PHPclassperson{ Public $name;  Public $gender;  Public functionsay () {Echo $this->name, "\tis",$this->gender, "\ r \ n"; }}classfamily{ Public $people;  Public $location;  Public functionConstruct$p,$loc) {$this->people=$p; $this->location=$loc; }}$student=NewPerson ();$student->name= ' Tom ';$student->gender= ' Male ';$student-say ();$tom=NewFamily$student, ' Peking ');

In the above code, two classes are defined, one is person, one is family, the object in the person class is created in the family class, the object is treated as a property of the family class, and the method that calls it handles the problem, which is called "combination."

　

2. Inheritance and combination difference

Class inheritance is statically defined at compile time and can be used directly, because the programming language directly supports class inheritance. Class inheritance makes it easier to change the implementation that is reused. When a subclass is redefining some, but not all, operations, it can also affect the operations it inherits, as long as the redefined operation is invoked in those operations.
But class inheritance also has some shortcomings. First, because inheritance is defined at compile time, it is not possible to change the implementation inherited from the parent class at run time. To make things worse, the parent class usually defines at least a specific representation of a subset of subclasses. Inheritance is often thought of as "breaking encapsulation" because inheriting subclasses reveals the implementation details of their parent classes. The implementation in the subclass has such a close dependency on its parent class that any changes in the parent class implementation will inevitably cause the subclass to change. When you need to reuse subclasses, there are some problems with implementing dependencies. If the inherited implementation is not suitable for solving the new problem, the parent class must be overridden or replaced by another more appropriate class. this dependency limits flexibility and ultimately limits reusability . An available workaround is to inherit only abstract classes , because abstract classes typically provide fewer implementations.

Object composition is dynamically defined at run time by obtaining a reference to another object. combinations require that objects adhere to each other's interface conventions , which in turn require more careful definition of interfaces that do not prevent you from using an object with other objects. This also produces good results: Because objects can only be accessed through the interface, we do not break the encapsulation; As long as the type is consistent, the runtime can also replace another object with one object, and further because the implementation of the object is based on the interface write, so there are fewer dependencies on the implementation .

Object composition has another effect on system design, which is that prioritizing the use of object combinations helps you keep each class encapsulated and focused on a single task. Such class and class inheritance hierarchies remain small and are unlikely to grow into uncontrollable behemoths. On the other hand, design based on object composition will have more objects (and fewer classes), and the behavior of the system will depend on the relationship between objects rather than being defined in a class .
This derives the second principle of our object-oriented design: Prioritize the use of object combinations rather than class inheritance .

Recommended reading "

A simple comparison of inheritance and composition in object-oriented programming

Object-Oriented Programming Concepts: combination (composition) and aggregation (aggregation)

Understanding composite objects and class inheritance