Object-Oriented Programming - Inheritance and Polymorphism

Professor Zhou Ligong's years of hard work "Programming and Data Structure" and "Programming for AMetal Framework and Interface (I)", the electronic version has been distributed to electronic engineers and college groups for free, after the content of the book is published, in electronic The industry has set off a learning boom. Authorized by Professor Zhou Ligong, this public number has serialized the contents of the book "Programming and Data Structure" and is willing to share it.

The fourth chapter is object-oriented programming . This article is 4.3 inheritance and polymorphism .

> > >    4.3.1 Abstraction

Suppose you need to design a packet that processes payroll, and you can abstract the sort as a key business. Although the implementation of various sorts is different, their commonality is "sorting", which is the basis of abstraction. If you want to build a matrix algebra package, you should discuss the abstract matrix. Although the implementations of the various types of matrices vary, they can be grouped into one class based on their common behavioral characteristics, and it is clear that their commonality once again supports abstraction.

If the user has a requirement to verify the data pushed onto the stack, the implementer must ask "What is the validation rule?" because validation is a very "abstract" concept; if the user explicitly tells the implementation - Performing a range value check or even parity on the data pushed onto the stack will not cause such ambiguity. When you need to perform range value validation on the data pushed to the stack, you need to write a RangeValidator class; when you need to add a parity checker, you must write an OddEvenValidator class. Obviously, every time you add a validator, you need to add an interface, and you can't reuse it at all.

Although their types are different and the objects of different validators are different, their common concept is the "verifier". The nature of the regression checker, no matter what the validator, its common property is the check parameter, the common behavior is that you can use the same method - in the dynamic call different checker functions according to the type of the object.

Obviously, the user puts forward the need for verification at the conceptual level to communicate with the implementer, and how the verification is performed at the implementation level, the user does not need to know exactly how to achieve it. So as long as the concept is the same, the user and the implementation details can be completely separated.

In process-oriented programming, the novice's understanding of commonality often comes from intuition. To create a range-value checker class and even-checker class, programmers generally express this commonality according to the following method, extracting Validate as a A public function pointer. such as:

For an experienced programmer with "object-oriented thinking", it is more inclined to package the commonality of various validators in a function pointer to create an abstract class as a member of the structure. The Validator abstract class is defined as follows:

Among them, pThis is a pointer to the current object, Validator is an abstract class with no specific attributes, representing a variety of specific validators of common data and behavior. The Validator class doesn't provide any code that implements the validate method. Because of this, the method can be an abstract method, because providing any code will make the method a concrete method.

Since the Validator is an abstract class, you can't create an instance. Naturally, you don't know what to verify. So who knows? The range value verifier and parity class know what to do with the check. Since the Validator has a validate method, you can wrap the Validator abstract class as a member of the RangeValidator derived class, the variable isa of the Validator class, and delegate the implementation details to the subclass. Redefine the range value validator and parity class, each implementing its own validate method.

> > > 4.3.2 Inheritance

A new concept inheritance will be introduced here to describe the relationship between classes. Since the commonality of the RangeValidator range value checker and the OddEvenValidator parity checker is the method of checking the parameters and calling the checksum function, the commonality is moved up to a class called the Validator validator class (parent class).

Based on this, a new struct data type can be created by transferring the variability check parameters to the RangeValidator and OddEvenValidator respectively, and using the variable isa of the Validator type as a member of the structure:

Among them, pThis is a pointer to the Validator class object, RangeValidator and OddEvenValidator are derived from the Validator class, RangeValidator and OddEvenValidator are subclasses of the Validator, and the Validator class is the base class or superclass of the RangeValidator and OddEvenValidatorr classes. Because the RangeValidator is a validator, the OddEvenvalidator is also a validator. When a subclass inherits from a base class, it can do anything the base class can do, so both RangeValidator and OddEvenValidator are extensions of the Validator.

Although the types of parent and child classes are different, when the common properties and behaviors of different classes are abstracted into a common base class through inheritance, they have common properties and behaviors. This is how OOP implements code reuse through inheritance. Methods. Because abstract classes conceptually define common properties and methods of a similar set of classes, this set of related classes can be considered a concept. That is to say, the abstract class represents the core concept of linking all derived classes, and it is this core concept that defines the commonality of derived classes. A communication interface specification for this group of related classes is also provided, and then each specific class provides a specific implementation as needed.

Thus, for a new abstraction, it must be placed in the context of the already designed class and object hierarchy. In fact, this is neither a top-down activity nor a bottom-up activity. Halbert and O'Brien point out, "When designing classes in a type hierarchy, it's not always starting with a base class, then creating subclasses. Usually creating types that look dissimilar, when they are aware that they are relevant Then separate their commonalities into a base class or multiple base classes..." Practical experience has shown that the design of classes and objects is an incremental, iterative process. Stroustrup believes that "the most common class hierarchy is organized by extracting public parts from two classes into a new class, or splitting a class into two new classes." For example, the commonality between RangeValidator and OddEvenValidator Move up to the Validator.

Since many developers often ignore the proper naming of objects and classes, you must ensure that when you create classes, properties, and method names, you must not only follow the conventions, but also make the names descriptive and at a glance. Otherwise, the right to interpret is in the programmer's own. Because of the personality of the programmer, it is often possible to create agreements that are only reasonable for themselves, while others are completely incomprehensible. Class names cannot be verbs. Class names should be named with common nouns, such as Validator or RangeValidator, avoiding class names such as Manager, Processor, Data, or Info. The object name should be named with the appropriate noun phrase, for example, rangeValidator or oddEvenValidator. In particular, the name chosen should be the name used and recognized by the business domain experts. The method name should be a verb or a verb phrase, for example, pushWithValidate.

When the developer decides to adopt a collaboration mode, the work is broken down into objects, which define the appropriate methods on the corresponding classes. In the final analysis, a single class protocol contains all the operations needed to implement all the behavior and all the mechanisms involved in implementing its instance. So like the design of a class hierarchy, the mechanism represents a strategic design decision.

In fact, mechanisms are models that are discovered and summarized in long-term practice. In the underlying development model, idiom is a form of expression; in the high-level development model, there is a set of classes. The framework represents large-scale reuse, such as ZLG's AMetal framework and AWorks framework, MVC framework and MVVM framework, and Microsoft's .NET framework or open source code. So the mechanism represents a level of reuse that is higher than the reuse of a single class.

Although the code shows the relationship between the base class and the subclass, it is still not profound enough. Here, the inheritance relationship between Validator and RangeValidator will be taken as an example, and further described by UML diagram, as shown in Figure 4.4.

Figure 4.4 Inheritance diagram

Why does the inheritance relationship point to the base class? Its profound design philosophy is that it represents the direction of dependence. A dependency is a relationship between two elements, where one element change will cause another element to change. UML diagrams use a hollow arrow from a subclass to the base class to indicate inheritance, suggesting that changes in the base class may result in subclass changes. In short, the first construction that is dependent on depends on the post construction of other elements.

In fact, inheritance is a very traditional and classic term. It was widely used since the advent of Smalltalk. The relationship between a generic class and its special class is called an inheritance relationship. It also appears in many ways as a verb or an adjective. For example, special classes inherit properties and operations of general classes, and object-oriented programming languages ​​have inheritance and encapsulation.

The general-specially appropriate relationship between a general class and its special class can be called a general-special relationship or a general-special structure. When the term "general" is translated into Chinese, it is easily confused with the context, so translation into "generalization" is more accurate. That is, the general class (parent class) is generalized for the special class (subclass), and vice versa. Therefore, the relationship between a general class and a special class is called a general-special relationship, and a general-special structure is a structure formed by a group of classes having a general-special relationship (inheritance relationship).

Obviously, the general-special structure is a kind of structure that exists objectively between various things in the problem domain. The general-special structure is established in the object-oriented analysis model, so that the model more clearly maps the classification relationship of things in the problem domain. Divide an object into classes and use classes to describe all object instances that belong to it. It organizes classes with general-special relationships, which simplifies the understanding of complex systems and makes people's understanding and description of the system closer to the general concepts and special concepts in everyday thinking.

In object-oriented development, the general-special structure allows the developer to simplify the definition of the class, so the common features of the object need only be given in the general class, and the special class automatically owns these features through inheritance, without having to repeat the definition. .

Different methodologies have different strategies for how to find general-special structures. The biggest problem makes people feel more dependent on intuition. If the analysis method is an art, it means that people have great uncertainty. In fact, using commonality and differential analysis tools, and looking at objects from three different perspectives of concepts, protocols, and implementations, you can simplify complex systems. See Embedded Software Engineering Methods and Practice Series for Object-Oriented Analysis and Design.

> > > 4.3.3 Responsibility Driven Design

OO emphasizes the discovery of software objects in the real world or business domain, and software objects behave completely differently from objects in the real world. Software objects communicate by sending messages in a peer-to-peer communication manner, and the interaction between objects in the real world and the environment, as well as the interaction of other objects dynamically reflecting objects in the real world, is much richer.

Experienced developers in the field of research, if they find a certain responsibilities or a network of relationships they are familiar with, they will remember how the problem was solved before. Which models have you tried before? What are the difficulties in the implementation? How are they solved? The lessons of previous attempts and failures are suddenly linked to new situations.

In order to truly reflect the dynamic interaction of objects in the real world, to make a class reused in different systems, you must fully consider scalability when designing classes. After a long period of accumulation, people have summarized a set of design principles for inspiring and guiding classes: Responsibility-driven design—how to assign responsibilities to objects in collaboration.

Obviously, for the rangeValidator object and the oddEvenValidator object, their responsibility is to perform range value checking and even checking on the data pushed to the stack, which means that there must be a corresponding method. Since each subclass is responsible for its own behavior, each subclass must provide not only a method called validate, but also its own implementation code. For example, both RangeValidator and OddEvenValidator have a validate method, the RangeValidator class contains code for range value validation, and the OddEvenValidator class must have parity code. They are all subclasses of Validator and must implement different versions of validate.

It goes without saying that OOP expresses the commonality of the validator more directly than POP: "Use the validate function pointer to call different functions according to the type of the object in the run, and the check parameter will be common through the pThis pointer to the current object reference. Partially packaged together to form an abstract class." When they have this commonality, it is easier to discuss the differences between the various validators.

In addition to the variable value, the commonality of the validateRange() check function of the RangeValidator class object is a judgment processing statement that satisfies the condition of the range value. The variable is the range value check parameters min and max; the validateOddEven() school of the OddEvenValidator class object The commonality of the test function is a judgment processing statement that conforms to the even-valued condition, and the variable is the even-check parameter isEven.

According to the principle of commonality and variability analysis, the same and identical processing parts are included in the abstract module, and the variables of the change discovered by the variability analysis are dealt with by the parameters passed in from the outside. Its function prototype is as follows:

Since the &rangeValidator.isa, &oddEvenValidator.isa, and pThis values ​​are equal and the types are the same, the range value checksum and the parity function's void * can be generalized to Validator *. When a base class object is replaced with its subclass object, the program will not generate any errors and exceptions, and the user does not have to know any differences, and vice versa. That is, if a piece of code uses methods from the base class, you must be able to use the objects of the derived class without having to make any modifications yourself. Therefore, in the program, try to use the base class type to define the object, determine its subclass type at runtime, and replace the base class object with the subclass object. This is the principle of replacement of the Richter, which was proposed by the 2008 Turing Award winner, Professor Barbara Liskov, the first female computer science doctor in the United States, and Professor Jeannette Wing of Carnegie Mellon University in 1994.

When applying the Richter replacement principle, the parent class should be designed as an abstract class or interface, let the child class inherit the parent class or implement the parent class interface, and implement the methods declared in the parent class. It is convenient to extend the functionality of the system by replacing the parent instance with a subclass instance at runtime. There is no need to modify the code of the original subclass, and adding new functions can be achieved by adding a new subclass. It can be seen that the principle of replacement of Richter is one of the important ways to achieve the principle of opening and closing.

If the principle of opening and closing is the goal of object-oriented design, then the principle of dependency inversion is one of the main principles of object-oriented design. It is the concrete realization of abstraction. The dependency inversion principle requires passing a high-level abstraction layer class when passing a parameter or in an association relationship, that is, using an interface and an abstract class for variable declaration, parameter type declaration, method return type declaration, and data type conversion. Wait, not to do these things with concrete classes.

In order to ensure the application of this principle, a concrete class should only implement methods declared in interfaces or abstract classes, rather than giving extra methods, otherwise it will not be possible to call new methods in subclasses. Obviously, after the abstraction layer is introduced, the concrete class is written in the configuration file. If the requirements change, you only need to extend the abstraction layer and modify the corresponding configuration file. Without modifying the code of the original system, the function of the system can be expanded to meet the principle of opening and closing. Generally, the principle of opening and closing, the principle of replacement of Richter and the principle of dependency inversion will occur at the same time. The principle of opening and closing is the goal. The principle of replacement of Richter is the basis. The principle of relying on the principle of inversion is the means. They complement each other and complement each other. The goal is the same, but the problem is analyzed. The angle is different.

Inheritance is one of the widely abused concepts in OO modeling and programming. If the LisKov replacement principle is violated, the inheritance hierarchy may still provide code reusability, but will lose scalability. So when using inheritance, think about whether a derived class can replace a base class. If not, ask yourself why you use inheritance? If you want to reuse the base class code when writing a new class, consider using a combination.

As with inheritance, composition is also a mechanism for building objects. Inheritance is used if the new class can replace existing classes and the relationship between them can be described as is-a. If the new class just uses existing classes and the relationship between them can be described as has-a, then the combination is used. Relative inheritance, the combination is more flexible and the applicability is stronger.

The use of the combination and examples will be explained in the subsequent related tutorials, combined with specific applications.

Here, the RangeValidator and OddEvenValidator classes extend (ie inherit) the Validator, and the implementation of the corresponding validator interface is detailed in Listing 4.9.

Listing 4.9 Implementation of the Universal Validator Interface (Validator.c)

Thus, abstraction is a powerful analytical tool that emphasizes what is common, so commonality and differential analysis naturally become the theoretical basis of abstraction. The commonality analysis looks for structures that cannot change over time, while the variability analysis finds structures that may change. If the change is a specific case in the "business area", then the commonality defines the concept of linking these situations in the business domain. The common concept is represented by abstract classes, and the changes discovered by variability analysis are implemented by concrete classes derived from abstract classes. Commonality and variability analysis tools not only guide us in creating abstract and derived classes, but also guide us in building abstractions and interfaces. Then the design process of the class is naturally simplified into two steps:

When defining an abstract class (common), you need to know what interface to use to handle all the responsibilities of this class;

When defining a derived class (variability), you need to know how it should be implemented according to a given specification for a given particular implementation (ie, change).

Obviously, a class is a programming language structure that describes all objects with the same responsibilities. Implement these responsibilities in the same way and share the same data structure. Although there may be some properties inside it, there may be some methods, but we only care about the object being responsible for its own behavior. Because the implementation is hidden behind the interface, the implementation of the object and the objects that use them are actually completely decoupled. So as long as the concept remains the same, the requester is isolated from changes in implementation details.

For ease of reading, Listing 4.10 shows the interface to the Universal Validator.

Listing 4.10 Common Validator Interface (validator.h)

Here, the range value checker is taken as an example. Assume that min=0, max=9. The method of initializing the structure using a macro named newRangeValidator as shown in Listing 4.10(22) is as follows:

The macro expands as follows:

Among them, the outer {} assigns a value to the RangeValidator structure, and the internal {} assigns a value to the member variable isa of the RangeValidator structure. which is:

If there are the following definitions:

That is, you can use the pValidator to reference the min and max of the RangeValidator.

Since pValidator and &rangeValidator.isa are not only of the same type, but their values ​​are equal, the following relationship holds:

So you can use this feature to get the address of the validateRange() function, ie pValidator->validate points to validateRange(). The form of its call is as follows:

At this point, maybe you will think that since their methods are the same, but the properties are different, why not combine them into one class? If you do this, the more responsibilities a class assumes, the less likely it is to be reused. And too many responsibilities of a class are equivalent to coupling these responsibilities together. When one of the responsibilities changes, it may affect the operation of other responsibilities. Therefore, these responsibilities should be separated, and different responsibilities should be encapsulated in different classes, that is, different reasons for change are encapsulated in different classes. If multiple responsibilities are always changing at the same time, they can be packaged in the same class.

That is to say, as far as a class is concerned, there should be only one reason for its change. This is the principle of single responsibility, which is the guiding principle for achieving high cohesion and low coupling. This is the simplest and most difficult to apply principle, requiring developers to discover the different responsibilities of the class and separate them.

> > > 4.3.4 Polymorphism

Polymorphism is an important feature of object-oriented programming. The literal meaning of polymorphism (function) is in many forms. The rules for operations in each class are the same, and these classes can implement these operations of the same name in different ways, so that objects with the same interface can be replaced at runtime.

When sending a message to an object, the object must have a defined method to respond to the message. In an inheritance hierarchy, all subclasses inherit interfaces from their superclass. Since each subclass is a separate entity, they may need to respond differently to the same message. For example, the Validator class and the behavior validate.

In object-oriented programming, what is actually referenced is a concrete instance of a class derived from an abstract class. When an abstract reference concept requires an object to do something, it will get different behaviors, depending on the specific type of the derived object. Therefore, in order to describe the variability expressed on the basis of the same characteristics between things, polymorphism is created, and polymorphism allows the same method (code) to handle objects of different behaviors.

Polymorphism is a binding mechanism that occurs at runtime based on the type of an object. This mechanism is used to bind a function name to a function that implements the code. When a program is executed, each function constituting the program has a storage space in the memory of the computer. The starting address of a function in the memory is the entry address of the function, so polymorphism is to dynamically bind the function name to The runtime binding mechanism of the function entry. Although polymorphism is closely related to inheritance, polymorphism is often seen as one of the most powerful advantages of object-oriented technology.

Obviously, calling the validator is to send a message that uses the validate function pointer. In fact, regardless of the range value verifier or the parity checker, the verification process is implemented by functions of different contents. In object-oriented programming, the methods for responding to messages are defined in different classes. When using these classes, you don't have to think about what type they are, just publish the message. Just as when calling the validator, you don't have to think about what checkers they call, just use the validate function pointer, no matter what type of validator can implement the check function.

Since both the RangValidator and OddEvenValidator classes inherit from the Validator class, there is no need to repeatedly define these properties and behaviors for each validator in the inheritance tree. Repetition not only needs to do more, it can even lead to errors and inconsistencies. See Figure 4.5 for details. This relationship is represented in UML as a line and has an arrow pointing to the parent class. This notation is very succinct and concise. When you encounter this line with arrows, you know that there is a relationship that inherits and presents polymorphism.

Figure 4.5 Hierarchy of abstract classes

When designing the Validator, it is helpful to standardize the use of various validators, because no matter what kind of validator, a method called validate is used. If you follow this specification, you only need to call the validate method whenever you want to validate the data. There is no need to consider what this is, so there is a truly polymorphic Validator framework - each object is responsible for the completion of the check, whether it is range value check, parity or prime check.

According to the principle of opening and closing, you need to write a pushWithValidate() function that extends the push function. The prototype is as follows:

If a range value check is required, pValidator points to rangeValidator, otherwise pValidator is set to NULL.

The specific implementation of pushWithValidate() is as follows:

The form of its call is as follows:

The application sample program using the universal validator is detailed in Listing 4.11.

Listing 4.11 Sample program using the generic validator

It can be seen that although the boundaries between OOA and OOD are vague, their focus is different. OOA focuses on the problem domain that is being analyzed, discovering classes and objects from the problem domain vocabulary, and modeling the real world. OOD focuses on how to design generalized abstractions and some new mechanisms that dictate how objects work together.