OO foundation inheritance
Rayleahaan@hotmail.com
1 inheritance
Traditional views generally divide inheritance into two types: achieve inheritance and interface inheritance. There are also many statements about these two inherits, and individuals accept Bjarne Stroustroup:
Realization inheritance: It is an implementation detail of subclasses, which is not reflected in the type of subclass (interface). Interface inheritance: also called subtyping, subclasses inherit the interface of the parent class, and allows the parent class type to the implicit conversion of the subclass type. That is, the parent class and subclasses are a base type-sub-type relationship that satisfies the LSP principle: The subtype must be replaced by its base type.
With my understanding, it is purely a realization technology to reuse other classes. Its starting point is a subclass, and the parent class is only part of the realization of subclasses. If dependent, the interface of the subclass and the interface of the parent class are not related. The interface inheritage expresses an alternative relationship between the object's object and the subclass of the subclass, and the interface of the subclass contains the interface of the parent class. In static language, such as C and Java, one of the key mechanisms that support abstraction and polymorphisms is that the interface inherit is inherited through the interface, and we can extend the base type without affecting the customer code. From the viewpoint of design, the inheritance is equivalent to inclusive, except for coverage issues (see 1). It is possible for simplicity considerations, and most of the object-oriented languages that appear late in the evening do not provide direct support to achieve inheritance. At this time, the inheritance is just inherited: Java uses Extends and Implements to represent, C # direct colon . C also provides more choices: express interface inheritage with public derived, derived with private and protected to express the inheritance.
2 inherited misuse
Inheritance misuse and abuse are common, especially those who have simply regarded inheriting another code multiplexing mechanism provided by the language layer. There are two main situations:
Inheritance in the use of inclusive places. It is very convenient to inherit the use of this misinterruption. It is also easy to write (can directly access the parent class's operation), but also pays the cost of adding dependencies: When the subclass covers the virtual function of the parent class The parent class will rely on its sub-class to implement its part of the function, of course, sometimes we will expect such a behavior, such as the case where the template method mode is applicable, but when our original is not this, the dependency Will bring trouble. If the inclusive relationship is misused into an interface inheritance, there is also a problem that I forget the implicit type conversion of the subclass to the parent class, unless your semantics allow this conversion. At the same time, inheritance also limits a parent object that limits a sub-objects that can only be included, there is not enough flexibility. The inclusive expression is a "HAS A" relationship, and the interface inherit is basically a "IS A" relationship, and the inheritance emphasizes an implementation details. Inheritance inheritance in the use of inheritance is used. If only the code multiplex is considered, the inheritance can be implemented, and the interface inheritance can be realized, and the interface inheritance also has the function of implementing inheritance of the inheritance interface, which is why the interface is often flooding. The result of this misuse is of course violating the LSP principles.
As can be seen from the above, it is not enough to simply think of another code multiplex, so Bjarne Stroustrup said: Basically, the derived (inheritance) should only be used to define a good relationship in the design of the design. The code is the expression of design ideas. Good code should be able to make readers correctly understand their design intent, such as, when you see a class D in the C program, the reader has reason to make such assumptions: In all functions written in B, if you are incorporated into the object, the function should keep the correct behavior. If the writer of the code, "I don't want to design", then the code is difficult to understand. 3 inheritance and UML
Finally, talk about the representation of inheritance in UML. Since UML is not only modeling software system, there is no inheritance relationship, and in order to use generalization relationship, use generalization relationship to express the inheritance relationship in the software field. If the interface is inherited, use a triangular shoulder pointing to the parent class directly, inheriting the implementation, by applying to a structural implementation on the generalization relationship, as shown below
References
[1] Bjarne Stroustrup. The C Programming Language (Special Edition). 1998. [2] Erich Gamma and ... Design Patterns: Elements of Resuable Object-Oriented Software. 2001. [3] Robert.c.martin Original, Deng Translation. Agile Software Development: Principle, Mode and Practice. 2003. [4] Grady Booch Out of Outline, Shao Weizhong and other translations. UML Guide, UML User Guide. 2002. [5] Timothy A. Budd Original, Huang Mingjun Object-oriented programming. 2002.
Last Modified: Sunday, March 27th, 2005
HTML Conversion by
TEX2PAGE 2005-02-27
