See Mountain is only a mountain, see water is only water--raise the understanding of inheritance

See Mountain is only the mountain see water is only water--raise the understanding of inheritance

Author: Wen Yu This article is published in the "Csdn Development master"

Encapsulation, inheritance and polymorphism are three characteristics of OO, which shows the importance of inheriting ideas. However, many people's understanding of inheritance is too limited to the OOP level, which restricts the great effect of inheriting thought on ood level. The author thinks, the software engineer should raise the understanding level to OO thought unceasingly, strengthen the actual development ability.

This paper, from the perspective of ood, regards inheritance as a powerful means to achieve ood, and through concrete examples, explains the three of interface programming (P Rogram to a Interface), mixed Class (Mix in Class), role-based design (role-based) Famous Ood skills that are closely related to inheritance.

First, from a Zen master quotations.

"Five Lantern Festival Yuan" Volume 17, there is a Qingyuan letter Zen master's Quotations: "Monk 30 years ago meditation, see Mountain is mountain, see water is water." And later, seeing the knowledge, there was a place to see the mountain is not a mountain, see water is not water. Now get a break, according to the former see Mountain is only a mountain, see water is only water. ”

Zen Master pontificate, quite philosophical, is about the process of enlightenment. In fact, the process of understanding the Ood of the road is not so it.

1, see Inheritance is inheritance--programmer realm

Beginners of OOP, mostly in the "See Inheritance is Inheritance" level, the most concern is the class syntax, class member variables, class member functions, such as the implementation layer of things. This is the programmer realm.

2, see Inheritance is not inheritance--the realm of growth

When you start to study Ood, you tend to jump to the other extreme, only care about the design, and inadvertently (and may be powerless) concerned about the realization, in the so-called "see Inheritance is not inherited" level. At this stage, the exciting point in the brain is "design", which is the concept of responsibility assignment, interface design, reusability, scalability, coupling, aggregation, and other design layers. This is the realm of growth.

3, see inheritance just inherit--designer Realm

After learning to pass the Ood, will achieve "see Inheritance just inherit" level. A "only" word, embodies the inheritance behind the "design concept" is the key to the realm. However, this stage and the second stage are different, the second stage is blindly negation, and this stage is the negation of the negative, the OOP level of the inheritance mechanism as a means to achieve a specific ood to use. This is the designer realm.

Second, from the Ood level to understand the inheritance

At the OOP level, in addition to the basic concepts of class, member variables, and member functions, the most important thing is code reuse and namespace visibility. At the Ood level, the most basic concept is the concept of class, duty, state and role, and its related coupling degree, aggregation degree, reusability, scalability, maintainability and so on. It can be seen that although Ood ultimately relies on OOP as a means of implementation, it is clear that ood and OOP are not at the same level of abstraction and have different conceptual systems and modes of thinking.

Again inherit. Simply from the OOP level, inheritance is a basic mechanism for extending application functionality through the reuse of parent functions, allowing you to quickly define new classes based on the old classes, and others to use inheritance only to gain accessibility to namespaces. However, from the Ood level, inheritance can evolve "is-a", "plays role of" and other abstract design concepts. Therefore, if people who are in the role of designer are restricted to OOP, the situation of "design is not enough" is unavoidable. In a word, it is very important to promote the understanding of inheritance and realize the ood intention of the two inheritance mechanisms, which are to utilize interface inheritance and implement inheritance.

There are a lot of ood techniques related to inheritance, and this article only discusses the three techniques for interfacing programming, mixing classes, role-based design, and the following illustration shows the relationship between them and inheritance.

Third, interface programming--Isolation changes

1. Related theories

Coupling is a synonym for dependence, defined as "a relationship between two elements, one of which changes, causing another element to change". Abstract coupling is defined as "if Class A maintains a reference to abstract class B, it is said that class A is abstract coupled to B".

The dependency inversion principle (Dependency inversion principle) formalized the concept of abstract coupling, clearly stating that it should be "dependent on abstract classes, not on specific classes".

Adherence to the above principles for interface programming has largely prevented the spread of changes, effectively isolating changes, and helping to enhance the reusability and scalability of the system.

2, for interface programming examples-for the architecture design

According to the classic Coad Ood theory, a project usually contains four layers: the user interface layer, the problem domain layer, the data management layer, and the system interaction layer, as shown in the following figure.

One of the great benefits of dividing an architecture into layers is that these layers form the natural boundaries of the development team-the skills that developers need for each layer are different. The development team at the user interface layer needs to understand the user interface toolkit that will be used; the development team of the data management layer needs to be familiar with the relevant databases, persistent tools, or file systems used; The development team of the system interaction layer needs to understand the communication protocol and the middleware products used; The problem area layer's development team does not need to know this knowledge, They need the deepest domain knowledge, as well as the relevant distributed object or component technology used.

However, to really make each development team maximize its own development, a stable architecture design is needed to ensure that the problem domain layer "does not depend on any other layer, and any other layer" depends on the problem domain layer. As shown in the following figure.

The implementation of the architecture design is very important, is to use the skills for interface programming. Take the one-way dependency of the system interaction layer on the problem domain layer as an example:

Ø If the system interaction layer wants to invoke the operation of the problem domain layer, call directly.

Ø If the problem domain layer is to invoke the operation of the system interaction layer, the problem domain team needs to define a generic abstract interface, call the abstract interface programmatically, and the system interaction team through the interface inheritance mechanism, define the subclass of the abstract interface, and the subclass completes the concrete implementation of the abstract interface.

The author once had a project that the system needed to change the system's data in real time to notify another system at the far end. The relevant design is shown in the following figure. In the problem domain layer, it contains only one abstract interface Cchangereporter, and does not care about the concrete implementation of Cchangereporter. The system interaction layer has the freedom to choose the specific implementation method, such as Csoapchangereporter is implemented using the SOAP communication protocol Cchangereporter, Ctcpchangereporter is the TCP The cchangereporter of the Protocol implementation. It is also easier to assume that, for technical or commercial reasons, it will be necessary to support multiple communication protocols in the future.

3, for interface programming examples--for class design

The author used the design Pattern design MIME code class, elaborated how to use the strategy pattern to design a reusable, easy to expand MIME class level, in which the abstract interface class Cmimealgo played a vital role, is summarized as follows.

The user uses the MIME encoding function through the cmimestring, the cmimestring allows the user to dynamically configure the MIME encoding in the operation process the concrete algorithm, the concrete MIME coding algorithm is provided by the Cmimealgo class level, the concrete Cmimealgo The instantiation of subclasses is done by cmimestring according to user's configuration, and to add new MIME coding algorithm, only new Cmimealgo subclass is implemented, and cmimestring dynamic instantiation code can be expanded simply. As shown in the following figure.

Four, mixed class--better reuse sex

1. Related theories

The mixed class is defined as "a class that is designed to be combined with other classes" to provide alternative interfaces or functions to other classes.

From the realization, the mixed class requires multiple inheritance, and the mixed class is usually an abstract class and cannot be instantiated.

The role of the mixed class is: it can not only improve the reusability of the function, reduce the code redundancy, but also can make the related "behavior" in a class, instead of distributing it into multiple classes, avoiding the problem of so-called "code scatter" and "Code interleaving", which improves maintainability.

2. Examples of mixed class

Look at a specific project. In a credit card customer service System project, it is required to be able to send multiple messages to the user in a variety of ways, and to adapt to future business development and changes.

The current system needs to support the delivery mode:

Ø print (and mail)

Øemail

Ø Fax

The delivery mode to be supported in the foreseeable future:

Ø Mobile Phone Message

ØPDA message

The current system needs to be supported for outgoing information:

Ø Credit card statement

Ø Credit Card Overdraft Collection

Foreseeable future to be supported for outgoing information:

Credit card new Business leaflet

Credit Card promotional Activity leaflet

Here are some design considerations. A way to send to support a variety of messages to be sent, we hope that the delivery function is very reusable; In order to facilitate the future to join the new Send mode and send information support, the design must have good scalability. The relevant design is shown in the following figure. It adopts the OOD technique of mixed class, and uses a csendabledoc as the mixed class to support the reuse of the sending function; Csendalbedoc also uses the strategy mode to support the extension of the sending mode.

Role-based design--using role-assembling collaboration

1. Related theories

Collaboration is defined as "the interaction of multiple objects to accomplish a certain goal." A role is defined as "abstraction of an object in a particular collaboration", which "defines only a subset of the object's characteristics that is meaningful to a collaboration". The concept of collaboration and role is very close to the real world, as in the following picture, Professor Jane plays three roles-mother, wife, professor.

The interface separation principle (Interface separation principle) believes in the idea that "multiple proprietary interfaces are superior to a single universal interface" because "any interface should have high cohesion" so that "the instance object of the class that implements the interface can be rendered only as a single role".

The significance of role-based design is that it is easy to construct new collaborations through the combination of existing roles to complete new functions. Also, from a UML class diagram, you can naturally export role-based design scenarios, such as:

The following design is naturally derived from the class diagram above:

2, role-based design examples

For example, a system to be developed whose background data source might be a relational database, a generic file, and possibly another private database. Since interfaces can isolate changes, we can define a single interface that serves all data customer classes. As shown in the following figure.

However, the above design violates the role-based design idea, and there is no guarantee that the "instance object of the class implementing the interface can be rendered only as a single role", which poses some problems. For example, there is a data customer class, do not need to insert, update and other functions, but only need to read the data operation, then obviously a "read" service "role" is the most reasonable design, but Crowsetmanager is so "wide" an interface. Ultimately, we can improve the design in this way, as shown in the following figure.

Reference documents:

"Design pattern" Erich Gamma is waiting for Li Yingjun to translate

Refactoring-Improving the design of existing code (photocopy version) Martin Fowler

"UML Object-oriented Design Foundation" Meilir Page-jones Baoxiaolu and other translations

Java Design: Objects, UML, and procedures Kirk knoernschild Luoyingwei Wang Xiaolin Translation

Principle and practice of feature driven development method Stephen R. Palmer, John M. felsing Xun Yu

"Object-oriented programming:role-based Design" W.mcumber slides from the web

"Role = INTERFACE:A merger of Concepts" Friedrich Steimann from Joop

"Use design pattern design MIME code class" Wen Yu "CSDN Development master" 1th phase