一个负责硬件接口设计的专家，皱着眉头，提出了疑问。
“钱老，您说的这个‘封装’，把数据和操作数据的行为绑在一起，听起来很有道理。但是，为什么一定要这么做？”
“我直接去修改那个‘温度’变量，不是更简单，更高效吗？为什么非要绕个圈子，去调用一个什么‘获取温度’的方法？”
这个问题，很有代表性。
在场的，大部分都是搞底层，搞硬件出身的工程师。
在他们的世界里，效率就是一切。
为了实现一个功能，路径越短，开销越小，就越好。
钱学民提出的这种“发消息”的模式，在他们看来，无疑是增加了很多不必要的中间环节，是“脱裤子放屁”。
“问得好。”
钱学敏赞许地点了点头。
“这个问题，触及了‘面向对象’的第二个核心思想——‘继承’。”
他没有直接回答，而是走到了另一块空白的黑板前。
“我们刚刚‘创造’了一个‘杯子’对象。现在，我们又有了一个新的需求，我们要创造一个‘保温杯’。”
“按照我们过去的思路，我们会怎么做？”
黄建功接口道：“很简单。复制一份‘杯子’的代码，然后给它增加一个‘保温’的属性，比如‘保温时长’，再修改一下‘自然冷却’的方法，让它的温度下降速度变慢。”
“没错。”钱学敏点头，“绝大多数人都会这么想。简单，直接，有效。”
“但是，如果之后我们又需要一个‘带把手的杯子’呢？再复制一份？需要一个‘玻璃杯’呢？再复制？”
“那如果，我们需要一个‘带把手的玻璃保温杯’呢？”
钱学敏的语速越来越快。
“你们会发现，你们的‘世界’里，出现了无数个看起来相似，但又略有不同的‘杯子’代码。它们每一个都独立存在。有一天，你发现所有杯子的‘注入’方法都有一个bug，你需要去修改它。那么，你需要找到所有这些杯子的代码，一个一个地，把它们全部改一遍。”
“而如果你漏掉了一个，那你的世界，就会出现不一致，就会出现混乱。”
“这就是‘过程式’思维的弊端。它善于解决独立的问题，但当问题变得复杂，当事物之间产生关联时，它就会制造出无穷无尽的‘维护地狱’！”
听着钱学敏的描述，在场的很多软件工程师