如果你令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（根据某物实现出）。