[Translation] Objective C ++, 3rd edition, chapter 6. Inheritance (inheritance) and object-oriented design (Object-Oriented Design)

Chapter 6. Inheritance (inheritance) and object-oriented design (Object-Oriented Design)

By Scott Meyers

Translator: fatalerror99 (itepub's nirvana)

Release: http://blog.csdn.net/fatalerror99/

Object-Oriented Programming (OOP) has been popular for almost 20 years. Therefore, you may be familiar with inheritance, derivation, and virtual functions) concepts. Even if you only use C for programming, you will not completely escape the embarrassment of OOP.

Even so, C ++'s OOP may be a little different from what you get used. Inheritance (inheritance) can be divided into single or multiple, and each inheritance (inheritance) relationship can be public, protected, or private. Each link can also be virtual or non-virtual. Then, the member function option is available. Virtual? Non-virtual? Pure virtual? And interaction with other language features. How do default parameter values and virtual functions affect each other? How does inheritance affect C ++'s Name Lookup rules )? Are there any other design choices? Is virtual function the best way to change the behavior of a class?

This chapter provides all the answers in sequence. In addition, I will explain the true meaning of different features in C ++-that is, when you use a specific structure, what do you actually express. For example, public inheritance (Public inheritance) means "is-a", and if you try to make it mean something else, you will be in trouble. Similarly, a virtual function means "interface must be inherited (the interface must be inherited)", while a non-virtual function (non-virtual function) it means "both interface and implementation must be inherited (both interfaces and implementations must be inherited )". Ignoring the differences between these meanings will cause a lot of troubles in C ++ programming.

If you understand the meaning of various C ++ features, you will find that your views on OOP have changed. It is no longer an exercise that distinguishes different language features, but a practice that determines what you need to describe about your software system. And once you know what to describe, converting it into C ++ is not that laborious.

This chapter contains the following content. Click to open it:

• Item 32: Make sure public inheritance models "is-"
• Item 33: Avoid hiding inherited names
• Item 34: differentiate between INHERITANCE OF INTERFACE AND INHERITANCE OF IMPLEMENTATION
• Item 35: consider alternatives to virtual functions
• Item 36: Never redefine an inherited non-virtual function
• Item 37: Never redefine a function's inherited default parameter value
• Item 38: Model "has-a" or "is-implemented-in-terms-of" Through Composition
• Item 39: use private inheritance judiciously
• Item 40: use multiple inheritance judiciously