See the mountain is only the mountain see the water is just water--raise the cognition of inheritance

See the mountain is only the mountain see the water is just water--raise the cognition of inheritance

Wen Yu

Encapsulation, inheritance and polymorphism are the three main features 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 the Ood level. The author believes that the software engineer should constantly improve the understanding of OO ideas and strengthen the practical development ability.

This article stands in the Ood angle, regards the inheritance as the realization Ood powerful method, through the concrete example, explains for the interface programming (program to an Interface), mixes the class (Mix in Class), the role-based design (role-based Design) These three famous Ood techniques that are closely related to inheritance.

First, from a Zen master's quotations.

"Five Lantern Festival Yuan" Volume 17, there is a Qingyuan but the Zen master's Quotations: "Old monk 30 years ago, when not meditation, see Mountain is a mountain, see water is water." And then saw the knowledge, there is a place, see the mountain is not a mountain, see water is not water. Now a break, according to the mountain is only a mountain, see water is just water. ”

Zen Master pontificate, philosophical, is about the process of enlightenment. In fact, the process of understanding the path of ood is not so.

1, see Inheritance is inheritance--programmer realm

Beginners of OOP, mostly in the "See Inheritance is inherited" level, the most concerned about the class of syntax, class member variables, class member functions and other such implementation layer of things. This is the programmer realm.

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

Beginning to study Ood, and often jump to the other extreme, only concerned about the design, but the unintentional (may be powerless) concerned about the realization, in the so-called "see Inheritance is not inheritance" level. At this stage, the point of excitement in the brain is "design", which is the concept of responsibility assignment, interface design, reusability, extensibility, coupling, aggregation, and other design layers. This is the growth realm.

3, see inherit only inherit--designer Realm

After learning to Ood, we will reach the level of "see Inheritance just inherit". A "only" word, embodies the inheritance behind the "design concept" is the key to the realm. However, this phase 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 use. This is the designer realm.

Ii. understanding inheritance from the Ood level

At the OOP level, in addition to the most basic concepts of classes, member variables, and member functions, the most important is the reuse of code and the visibility of namespaces. At the Ood level, the most basic concepts are the concepts of class, responsibility, state and role, which are more abstract, and their related coupling degree, aggregation degree, reusability, extensibility, 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, with different conceptual systems and ways of thinking.

Say inheritance. Purely from the OOP level, inheritance is a basic mechanism for extending the functionality of the application by reusing the parent function, which allows you to quickly define new classes based on the old classes, and some people use inheritance only to get the accessibility of the namespaces. However, from the Ood level, inheritance can evolve the abstract design concepts of "is-a" and "Plays Role of". As a result, the "design persisting" situation is unavoidable if the designer's role is confined to the OOP level. In a word, it is very important to promote the understanding of inheritance and to realize the Ood intention by utilizing both inheritance mechanisms of interface inheritance and inheritance.

There are many ood techniques associated with inheritance, and this article only discusses three techniques for interface programming, mixed-class, role-based design, and the following diagram shows their relationship to inheritance.

Third, for the interface programming--Isolation change

1. Related theories

Coupling is a synonym for dependency, defined as "a relationship between two elements, where one element changes, causing another element to change". Abstract coupling is defined as "if Class A maintains a reference to the abstract class B, then class A is said to be 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 the abstract class, not on the concrete class".

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

2, for the interface programming example-for the architecture design

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

One of the great benefits of dividing the architecture into tiers is that these layers form the natural demarcation of the development team-the skills required for each layer of developers 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 database, persistent tools or the file system used, the development team of the system interaction layer needs to understand the communication protocol and the middleware products used, and the development team of the problem domain layer does not need to know They need the deepest domain knowledge, and the associated distributed object or component technology used.

However, to really make each development team to maximize the independent development, but also need a stable architecture design to ensure that the core idea is that the problem domain layer "does not depend on" any other layer, and any other layer "only depends on" the problem domain layer. As shown in the following figure.

The implementation of this architecture design is of paramount importance to the use of programming techniques for interfaces. Take the system interaction layer to the problem domain layer one-way dependence as an example:

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

Ø If the problem domain layer is to invoke the operation of the system interaction layer, it is necessary to define a general abstract interface by the problem domain team, and call this abstract interface by programming the interface, while the system interaction group defines the subclass of the abstract interface through the interface inheritance mechanism, which completes the concrete implementation of the abstract interface.

The author has a project that the system needs to change the data of the system in real time, notifying the far end of another system. The relevant design is shown in the following figure. In the problem domain layer, it contains only an abstract interface Cchangereporter, not the specific implementation of Cchangereporter. The system interaction layer has the freedom to choose a specific implementation method, such as Csoapchangereporter is implemented with the SOAP communication protocol Cchangereporter, Ctcpchangereporter is a cchangereporter implemented with the TCP protocol. It is also easier to assume support for multiple communication protocols in the future, for technical or commercial reasons.

3, for the interface programming example--for the class design

In the article "Using design mode to design MIME encoding class", the author describes how to design a reusable and easily extensible MIME class hierarchy using the strategy model, in which the abstract interface class Cmimealgo plays a very important role, which is briefly described below.

The user uses MIME-encoded functions through cmimestring, Cmimestring allows the user to dynamically configure MIME encoding in the process of operation, the specific MIME encoding algorithm is provided by the Cmimealgo class level, The instantiation of the specific Cmimealgo subclass is performed dynamically by the cmimestring according to the user's configuration; To add a new MIME encoding algorithm, simply implement the new Cmimealgo subclass and simply expand the cmimestring dynamic instantiation code. As shown in the following figure.

Iv. mixing Classes--better reusability

1. Related theories

A mixed class is defined as "a class that is designed to be combined with other classes by inheritance", which provides alternative interfaces or functions to other classes.

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

The effect of mixing classes is that it not only improves the reusability of functions, but also reduces the redundancy of code, and it can make the related "behaviors" in one class instead of distributing them into multiple classes, avoiding the so-called "code dispersion" and "code interleaving" problems, which improves maintainability.

2. Examples of mixed classes

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

The current system needs to support the sending method:

Ø printing (and mailing)

Øemail

Ø Fax

The foreseeable future to support the delivery method:

Ø Mobile SMS

ØPDA message

Current system needs to support the message to be sent:

Ø Credit card statement

Ø Credit Card Overdraft Collection order

Upcoming messages to be supported in the foreseeable future:

Ø Credit card New Business Flyer

Ø Credit Card Promotion Flyer

Here are some design considerations. One way to send to support a variety of messages to be sent, we want to send the function is very good reusability, in order to facilitate the future to join the new sending mode and send information support, design must have good scalability. The relevant design is shown in the following figure. It uses the Ood technique of mixing class, uses a Csendabledoc as the mixed class, supports the reuse of sending function, and Csendalbedoc also adopts the policy mode to support the extension of sending mode.

Role-based design-using role assembly collaboration

1. Related theories

Collaboration is defined as "the interaction of multiple objects in order to accomplish a certain goal." A role is defined as "an 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 character is close to the real world, as in the following illustration, Professor Jane plays three roles-mother, wife, professor.

The principle of interface separation (Interface separation Principle) embraces the idea that "multiple dedicated interfaces outperform a single universal interface" because "any interface should have high cohesion" so that "instance objects of classes that implement the interface can only be rendered 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 accomplish new functionality. Furthermore, a role-based design can be derived naturally from UML class diagrams, such as:

It is natural to export the following design 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, or possibly another private database. Since interfaces can isolate changes, we can define a single interface that serves all of the data client classes. As shown in the following figure.

However, the above design violates the concept of role-based design, and there is no guarantee that the "instance object of the class implementing the interface can only be presented 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, and only need to read the data, it is obvious that a "read" service "role" is the most reasonable design, but Crowsetmanager is so "wide" an interface. Finally, we can improve the design as shown in the figure below.

Reference documents:

"Design pattern" Erich Gamma is waiting for the translation of Li Yingjun

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

The foundation of UML object-oriented design Meilir page-jones the translation of Baoxiaolu

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

The principle and practice of feature-driven development methods 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

"Using design mode to design MIME coding class" Wen Yu "CSDN development expert" 1th issue

and a number of articles from www.objectmentor.com.

Author Profile:

Wen Yu, architecture designer, Senior consultant, founder of Loose coupling Space (http://lcspace.nease.net). Good at object-oriented, architecture and framework design, in-depth research on design patterns, UML and software engineering. You can contact the author by wenyu@china.com.