代码复制粘贴一时爽，后期维护火葬场。
这几乎是他们工作中，每天都在上演的悲剧。
“那么，在‘面向对象’的世界里，我们该如何创造一个‘保温杯’呢？“
钱学敏回到黑板前，用粉笔，在“杯子”的定义下面，画了一个箭头，指向了一个新的定义。
`定义 保温杯 : 继承 杯子 {`
` // 新增属性`
` 保温材质;`
` // 重写行为`
` 方法: 自然冷却() {`
` // 实现更慢的冷却逻辑`
` }`
`}`
“看。”
钱学敏指着这个简单的定义。
“这就是答案。”
“我们不需要复制任何代码。我们只需要告诉这个世界：‘保温杯’，是一种‘杯子’。它‘继承’了‘杯子’所有的属性和行为。”
“一个‘杯子’能做的事情，比如‘注入’、‘倒出’，‘保温杯’天然就能做。我们不需要再写一遍。”
“我们唯一需要做的，就是定义‘保温杯’和‘杯子’不一样的地方。比如，它有特殊的‘保温材质’，以及它有一个被‘重写’了的，更厉害的‘自然冷却’方法。”
“这就是【继承】！”
“它是一种‘is-a’（是一种）的关系。它让我们能够复用已有的代码，在不修改原有世界规则的基础上，去扩展和定义新的事物。”
“现在，我们再来回答刚才那位同志的问题。”钱学敏的目光，回到了最开始提问的那个硬件专家身上。
“为什么我们不直接修改‘温度’变量，而要通过‘获取温度’的方法？”
“因为，如果我们把‘温度’这个属性，直接暴露给外界，那么，当‘保温杯’继承‘杯子’的时候，它就继承了一个可以直接被外界修改的‘温度’。这破坏了‘保温杯’自身的‘封装’性。”
“但如果我们从一开始，就规定，所有对‘温度’的操作，都必须通过‘方法’来进行。那么，‘保温杯’继承的，就是这些‘方法’。”
“当外界调用‘自然冷却’这个方法时，‘杯子’执行的是普通版的逻辑，而‘保温杯’执行的，是它自己‘重写’过的加强版逻辑。”
“外界并不需要知道，它操作的到底是一个‘杯子’，还是一个‘保温杯’。它只需要知道，这个东西，