继承可以构建一个类型层次结构，来表示待解决的某种类型问题(构建出了相似的问题模型，故可解决相似的问题)。
  因为不需要在问题描述和解决方案描述之间建立许多中间模型，通过使用对象，类型层次结构成为了主要模型，因此，可以直接从真实世界中对系统的描述过渡到用代码对系统进行描述。(使用面向对象的思考方式考虑问题是从难到易)
  当继承现有类型时(继承父类的子类此时就成为了新的类型)，这个新类不仅包括现有类型的所有成员(不包括private私有成员)，而且更重要的是它复制了父类的接口(方法或行为)，所有发送给父类对象的消息同时也能发送给子类对象，所以这也就意味着子类与父类具有相同的类型。(圆形与几何 & 水果与苹果)
  由于父类和子类具有相同的基础接口(方法或行为)，所以伴随此接口的必定有某些具体实现，也就是说当对象接收到特定消息时，必须有某些代码去执行。父类与子类拥有相同的行为似乎没什么意义。
  有两种方法可以使父类与子类产生差异，第一种：直接在子类中添加新方法，这些方法是父类不具有的，不是父类接口的一部份，这也意味着父类不能满足你的要求，因此必须添加新的方法，这是对继承的简单使用方法。
  但是，是否存在父类也需要这些额外的方法？？
  第二种也是更重要的一种使父类和子类之间产生差异的方法是改变现有子类的方法和行为，即覆盖(重写)，直接在子类中创建该方法的新定义即可，同样的接口产生不同的行为。
  继承应该只是覆盖父类的方法吗？而不添加新方法？如果这样做，这意味父类和子类是完全相同的类型，因为它们具有完全相同的接口，结果可以用一个导出类对象来完全替代一个基类对象。这种情况下的关系称为(is - a 是一个)的关系，如：苹果是水果，圆形是几何形状。判断是否继承，就是要确定是否可以用is-a来描述类之间的关系。
  有时必须在子类中添加新的元素，这样也就扩展了接口，这个新类依旧可以替代父类，但这种替代并不完美，这个情况我们称为(is-like-a 像是一个)关系。
子类具有父类的所有方法，但是它还包含其他方法，所以不能说它们完全相同，以制冷器为例如果制冷接口坏了，你用一个即制冷又能制热的热力泵替代了它，那么这个热力泵就是is-like-a制冷器，它可以做更多的事情。尽管新对对象的接口已经被扩展，但是现有系统(问题模型)除了原来的接口之外，对其它东西一无所知。

  那么如何选择这两种呢？

  继承可以构建一个类型层次结构，来表示待解决的某种类型问题(构建出了相似的问题模型，故可解决相似的问题)。
  因为不需要在问题描述和解决方案描述之间建立许多中间模型，通过使用对象，类型层次结构成为了主要模型，因此，可以直接从真实世界中对系统的描述过渡到用代码对系统进行描述。(使用面向对象的思考方式考虑问题是从难到易)
  当继承现有类型时(继承父类的子类此时就成为了新的类型)，这个新类不仅包括现有类型的所有成员(不包括private私有成员)，而且更重要的是它复制了父类的接口(方法或行为)，所有发送给父类对象的消息同时也能发送给子类对象，所以这也就意味着子类与父类具有相同的类型。(圆形与几何 & 水果与苹果)
  由于父类和子类具有相同的基础接口(方法或行为)，所以伴随此接口的必定有某些具体实现，也就是说当对象接收到特定消息时，必须有某些代码去执行。父类与子类拥有相同的行为似乎没什么意义。
  有两种方法可以使父类与子类产生差异，第一种：直接在子类中添加新方法，这些方法是父类不具有的，不是父类接口的一部份，这也意味着父类不能满足你的要求，因此必须添加新的方法，这是对继承的简单使用方法。
  但是，是否存在父类也需要这些额外的方法？？
  第二种也是更重要的一种使父类和子类之间产生差异的方法是改变现有子类的方法和行为，即覆盖(重写)，直接在子类中创建该方法的新定义即可，同样的接口产生不同的行为。
  继承应该只是覆盖父类的方法吗？而不添加新方法？如果这样做，这意味父类和子类是完全相同的类型，因为它们具有完全相同的接口，结果可以用一个导出类对象来完全替代一个基类对象。这种情况下的关系称为(is - a 是一个)的关系，如：苹果是水果，圆形是几何形状。判断是否继承，就是要确定是否可以用is-a来描述类之间的关系。
  有时必须在子类中添加新的元素，这样也就扩展了接口，这个新类依旧可以替代父类，但这种替代并不完美，这个情况我们称为(is-like-a 像是一个)关系。
子类具有父类的所有方法，但是它还包含其他方法，所以不能说它们完全相同，以制冷器为例如果制冷接口坏了，你用一个即制冷又能制热的热力泵替代了它，那么这个热力泵就是is-like-a制冷器，它可以做更多的事情。尽管新对对象的接口已经被扩展，但是现有系统(问题模型)除了原来的接口之外，对其它东西一无所知。

  那么如何选择这两种呢？