Seeing the mountain is just the water is just water - improvement to inheritance
Temperament
Package, inheritance, polymorphism is the three major characteristics of oo, whereby the importance of inheritance thinking. However, many people have limited to the inheritance of the OOP level, thus limiting the huge role of inheritance ideas in the OOD level. The author believes that software engineers should continue to improve the level of understanding of OO ideas and strengthen actual development capabilities.
This article is at the point of OOD, and inherits the inheritance as a powerful means of achieving OOD, through specific examples, aware-based design (Mix In Class), role-based design (Role-Based Design) These three famous OOD tricks related to inheritance.
First, come from a Zen master
"Five Lighting Will Yuan" Volume 17, there is a Qinglan, only the quotation of the Zen Master: "When the old man did not participate in meditation 30 years ago, see the mountain is the mountain, see water is water. And to the later king, there is a Seeing the mountain is not a mountain, seeing water is not water. Today, I have a takecle, and I will see the mountain is just a mountain, and I see water is just water. "
The historicalism of Zen Master is quite philosophical, and it is the process of understanding. In fact, what is the process of comprehend the OOD?
1. See inheritance is inheritance - programmer's realm
People who begin to learn OOP, most of the level of "see inheritance is inherited", most concerned about the grammar, class member variables, member functions of class, and other things. This is the realm of programmers.
2, see inheritance is not inherited - growth realm
When starting to study OOD, it is often jumped to another extreme, only cares for design, and no heart (possibilities can be unable) care, and it is at the so-called "see inheritance is not inherited". In this stage, the excitement in the brain is "design", is the concept of responsibilities, interface design, reusability, scalability, coupling, and polymerization. This is a realm of growth.
3, see inheritance is just inheritance - designer realm
After learning OOD, it will reach the level of "see inheritance just inheritance". A "only" word reflects the "design concept" behind inheritance is the key to the realm. However, this phase and the second stage are different, the second phase is a noble denies, and this phase is negative, regarding the inheritance mechanism of the OOP level as a means of implementing a particular OD. This is the realm of the designer.
Second, from the OOD level understanding inheritance
At the OOP level, in addition to class, member variables, member functions These most basic concepts are the visibility of code reuse and name space. The OOD level, the most basic concept is class, responsibilities, state, and role these more abstract levels of the concept, and its associated coupling, polymerization, reusability, scalability, maintainability, etc. It can be seen that although OOD is ultimately relying on OOP as an implementation means, it is clear that OOD and OOP are not in the same abstraction level, there are different conceptual systems and thinking.
Spend inheritance. From the OOP level, inheritance is a basic mechanism for extending application functions by multiplexing parent class, which allows you to define new classes based on old class; others use inheritance only to get accessibility to namespaces. . However, from the OOD level, inheritance can evolve "IS-A", "Plays Role of", etc. Abstract design concepts. Therefore, people who are designer roles should be limited to the OOP level, and the situation of "design" is inevitable. In short, improve the inheritance of the inheritance, inheriting the two inheritance mechanisms for the inheritance mechanism, to achieve the OOD intent.
There are many OOD techniques associated with inheritance. This article only discusses three techniques than interface programming, mixing, and role-based design, the following figure shows the relationship between them and inheritance.
Third, targeting interface programming - isolation changes
1. Related theory
Coupling is a synonym of dependencies, defined as "a relationship between two elements, one of which changes, resulting in another elementary change." Abstract coupling is defined as "If class A maintains a reference to abstract class B, the class A abstraction is called B". Dependency Inversion Principle forms the concept of abstract coupling, explicitly expressing "depending on abstract classes, do not depend on specific classes".
Observe the above principles for interface programming, to a large extent, the expansion of the variation fluid, effectively isolating changes, helps to enhance the reusability and scalability of the system.
2. Application for interfaces - for architecture design
According to classic COAD's OOD theory, a project usually contains four layers: user interface layers, problem domain layers, data management, system interactive layers, as shown below.
A great advantage of dividing the architecture into layers is that these layers form a natural boundary of the development team - the skills needed for each layer of developers are different. The development team of the user interface needs to understand the user interface toolkit will be used; the data management development team needs to be familiar with the related database, persistent tools or file systems used; system interactive development teams need to understand communication protocols and used Middleware products; the development team of the problem area does not need to understand these knowledge, they need the deepest domain knowledge, and the related distribution objects or components technology.
However, it is necessary to truly develop the development team to maximize independently, and a stable architecture design is guaranteed. The core idea of its design is: the problem area "does not depend on" other layers, and any other layer "Only depends on" "problem field layer. As shown below.
The implementation of the architecture design is extremely important, which is to use skills for interface programming. Taking the single-directional dependence of the problem in the field of system interactive as an example:
Ø If the system intertrs should call the operation of the problem area, they can be called directly.
Ø If the problem area is to call the system interactive operation, you need to define a universal abstract interface by the problem domain team, and call this abstract interface by programming the interface; and the system interactive team uses the interface inheritance mechanism to define the subclass of the abstract interface. The subclass completes the specific implementation of the abstract interface.
The author has a project that needs to change the data of the system in real time to another system of the remote end. The designs are shown below. In the problem area, only one abstract interface CCHANGEREPORTER is included, but does not care about the specific implementation of CCHANGEREPORTER. The system interactive layer has the freedom to select the specific implementation method, such as CSoAPChangeReporter is the cchangereporter implemented with the SOAP communication protocol, and CTCPChangeReporter is the CChangeReporter implemented with TCP protocol. And assume that due to technical or commercial reasons, it is easier to support multiple communication protocols in the future.
3. Application for Interface - Used for Class Design
In the article "Design MIME Code Class", the author describes how to use the policy mode to design a reusable, easy to expand the MIME class level, where the abstract interface class cmimealgo has played a crucial role, simplification The following are below.
The user uses the MIME encoded by cmImeString, cmImeString allows the user to dynamically configure the specific algorithm for MIME encoding during operation; the specific MIME encoding algorithm is provided by the CMIMEALGO class level, and the specific CMIMEALGO subclass is modified by cmImeString according to user configuration dynamics Completed; to add a new MIME encoding algorithm, just implement the new cmimealgo subclass, and simply expand the dynamic instantiation code of cmImeString. As shown below.
Fourth, mix into class - better reuse
1. The related theory mixed class is defined as "a class designed to bind to other classes", which provides optional interface or functionality to other classes.
From the implementation, the mixing requirements are more inherited; mixed into the class is usually an abstract class, and cannot be instantiated.
The effect of mixing is: it can not only improve the reuse of the function, reduce the code redundancy; but also enable the relevant "behavior" in a class, rather than being distributed into multiple classes, avoiding so-called " Code dispersion "and" code intertwined "problem increases maintainability.
2. Example of mixing
To look at a specific project. In a credit card customer service system project, it is required to send a variety of information to the user in a variety of ways, and can adapt to the development of future services.
The current system needs to support the way:
Ø Print (and mailed)
Ø email
Ø fax
The predictable future to support the way:
Ø SMS
Ø PDA message
The current system needs to send information:
Ø Credit card statement
Ø Credit card overdraft resumption
Precious future to send information:
Ø Credit card new business leaflet
Ø Credit card promotion leaflet
Here are some design considerations. A sending method must support multiple pending information, we want to send functions to have a good reusability; in order to facilitate future addition to new transmission methods and send information support, design must have good scalability. The designs are shown below. Among them, it uses an OOD tip that is mixed. It is used as a CSendableDoc as an mixed class, and the reuse of the transmit function is supported; CSendalbedoc has the policy mode supports the delivery mode. Expansion.
V. Role-based design - use role assembly collaboration
1. Related theory
Collaboration is defined as "Multiple objects interacts in order to complete a certain goal." The role is defined as "Abstraction of the object in a specific collaboration", "which" only defines a subset of a collaborative significance for the object characteristics. The concepts of collaboration and roles and the real world are very close, such as the following figure, Professor Jane plays three characters - mother, wife, professor.
Interface Separation Principle believes in the idea of "multiple private interfaces better than a single general interface", because "any interface should have high cohesiveness", so that "guarantees instance objects that implement the interface of the interface. Only presented as a single role. "
The meaning of role-based design is that we can easily construct new collaboration through a combination of an existing role to complete new features. Moreover, the role-based design can be naturally derived from the UML class diagram, for example:
From the above class diagram, it is naturally derived from the following design:
2, role-based design example
For example, a system to be developed, its background data source may be a relational database, a general file, or another private database. Since the interface can be variable, we can define a single interface to serve all the data customer classes. As shown below.
However, the above design violates roles based on role-based design ideas, and does not guarantee "instance objects that implement this interface can only be single role", which will bring some problems. For example, there is a data customer class, does not need to insert, update and other functions, but only need to read the data, at this time, it is clear that "role" that provides "read" service is the most reasonable design, but CrowsetManager is so "Wide" one interface. In the end, we can improve the design like this, as shown below.
references:
"Design mode" Erich Gamma is waiting for Li Yingjun and other translations
"Reconstruction - Improves the design of existing code (copy version)" Martin Fowler
"UML object-oriented design foundation" MEILIR Page-Jones "Java Design: Object, UML and Process" Kirk Knoernschild "Kirk Knoernschild" Kirk Knoernschild
"Principle and Practice of Feature Drive Development Method" Stephen R. Palmer, John M. Felsing Western Zhou
"Object-Oriented Programming: role-based design" W.Mcumber from the web
"Role = interface: a merger of concepts" Friedrich Steimann from Joop
"Apply Design Mode Design MIME Code" Wen Wei "9CBS Development Master" No. 1
And multiple articles from www.objectmentor.com
About the author: Wen Wei, architect designer, senior consultant, loose coupling space (http://lcspace.nese.net) founder. Good at object-oriented, architecture, and frame design, have an in-depth study of design patterns, UML and software engineering. You can contact the author via wenyu@china.com and the author.
