条款 32:确定你的 public 继承塑模出 is-a 关系

《Effective C++ 中文版 第三版》读书笔记

** 条款 32:确定你的 public 继承塑模出 is-a 关系 **

如果你令 class D 以 public 形式继承 class B,你便是告诉 C++ 编译器,每一个类型为 D 的对象同时也是一个类型为 B 的对象,反之不成立。

B 比 D 表现出更一般化的概念,D 比 B 更特殊化的概念。任何函数如果期望获得一个类型为 B(或pointer to B或reference-to-B)的实参,都也愿意接受一个 D 对象(或 pointer-to-D 或 reference-to-D)。这个论点只有对 public 继承才成立。

class Bird{ 
    virtual void fly(); // 鸟可以飞 
    ... 
}; 

class Penguin: public Bird{ //企鹅是一种鸟 
... 
};

我们突然遇到了乱流,因为这个继承体系说企鹅会飞,而我们知道这不是真的。

我们成了不严谨语言的牺牲品。当我们说鸟会飞的时候,我们真正的意思并不是说所有的鸟都会飞,我们要说的只是一般的鸟都有飞行能力。我们来到以下的继承关系,他塑造出较佳的真实性:

class Bird 
{ 
    ...   // 没有声明fly函数 
}; 

class FlyingBird : public Bird{ 
    virtual void fly(); 
    ... 
}; 

class Penguin: public Bird{ 
    ...//没有声明fly函数 
};

这样的继承体系比原来的更能忠实的反应我们真正的意思。

如果你的程序忙着处理鸟喙和鸟翅,完全不在乎飞行,原来的 “双 class 继承体系” 或许相当令人满足了。这反映出一个事实,世界上并不存在一个 “适用于所有软件的” 完美设计。所谓最佳设计,取决于系统希望做什么事,包括现在与未来。如果你的程序对飞行一无所知,并且也不打算未来对飞行“有所知”,那么不去区分会飞的鸟与不会飞的鸟,不失为一个完美而有效的设计。

另一种派别在处理“所有鸟都会飞,企鹅是鸟, 但是企鹅不会飞”的问题,就是为企鹅重新定义 fly 函数,令他产生一个运行期错误:

void error(const std::string& msg); 

class Penguin : public Bird { 
    virtual void fly() {error("Attempt to make a pengnin fly!");} 
};

你必须认知这里所说的某些东西和你所想的不同,这里并不是说 “企鹅不会飞”,而是说 “企鹅会飞,但尝试那么做是一种错误”。

为了表现 “企鹅不会飞” 这样的限制,你不可以为 penguin 定义 fly 函数。

class Bird 
{ 
... // 没有声明fly函数 
}; 

class Penguin: public Bird{ 
... // 没有声明fly函数 
};

现在,如果你试图让企鹅飞,编译器会对你的背信加以谴责。

条款 18 说过:好的接口可以防止无效的代码通过编译,因此你宁可采取 “在编译期拒绝企鹅飞行”的设计,而不是 “只在运行期才能侦测他们” 的设计。

另一个例子,考虑这段代码:

class Rectangle { 
public: 
    virtual void setHeight(int newHeight); 
    virtual void setWidth(itn newWidth); 
    virtual int height() const; 
    virtual int width() const; 
}; 

void makeBigger(Rectangle& r) 
{ 
    int oldHeight = r.height(); 
    r.setWidth(r.width() + 10); 
    ASSERT(r.height() == oldHeight); 
}

class Square : public Rectangle {...};//正方形 继承 矩形 

Square s; 
ASSERT(s.width() == s.height()); 

makeBigger(s); 
ASSERT(s.width() == s.height());

调用makeBigger之前,s的高度和宽度相同;
在makeBigger函数内,s的宽度改变,但高度不变;
makeBigger返回之后,s的高度再度和宽度相同。(注意s是以by reference传递给makeBigger)

?本例的根本困难是,某些可能施行于矩形身上的事情,却不可施行于正方形身上。但是 public 继承主张,能够施行于 base class 对象身上的每件事,也一定都可以施行于 derived class 对象身上,在正方形和矩形的例子中,那样的主张无法保持,所以以 public 继承塑模他们之间的关系并不正确。编译器会让你通过,但是一如我们所见,这并不保证程序的行为正确。

is a 并不是唯一存在 classes 之间的关系。另两个常见的关系是 has-a(有一个)和 is-implemented-in-term-of(根据某物实现出)。

** 请记住: **
“public 继承” 意味 is-a。适用于 base class 身上的每一件事情一定也适用于 derived class 身上,因为每一个 derived class 对象也都是一个 base class 对象。

你可能感兴趣的:(条款 32:确定你的 public 继承塑模出 is-a 关系)