“你好，阿米戈！今天我要为你介绍 OOP 的另一个优点。你看，相较于建筑，程序更像动物。它们不是堆砌起来的，而是一点点成长起来的。开发意味着持续不断的变化。在建筑世界，你可以先制定好一个计划，然后按部就班地实施它。但是在软件开发方面，可不是这回事。”
多数情况下，你不能按照自己的意愿做事，而且你必须反复重新修改你的程序。更多的时候，客户的需求也会改来改去。
“但如果客户确实提供了一个详尽的规范说明呢？”
“回想一下以往的经历。”如果一个产品成功了，客户会想发布新的版本，然后再发布一个，再发布一个。当然，你或许还要对当前版本做一些“小小的改动”。因此，软件开发是一系列漫长的更改。只是节奏不同而已。新版本可能每周发布一次，每月一次，或每半年一次。”
“我们可以从中总结出什么道理呢？”
“以最小幅度的重写来执行大量（和小量）改动是产品内部结构维护的最佳之选。”
“具体怎么做呢？”
“我们已经讲过程序里的对象相互之间如何交互。我们在黑板上用实心点来代表程序里的对象。我们用箭头来把每个对象（实心点）和所有与它交互的对象（实心点）连起来。”
现在我们把这些对象（实心点）划分群组。同一组的实心点之间联系的总比与其他组的要多些。如果一个点的箭头指向的大多是它同一组的点，那我们的对象分组就是正确的。同一组的点之间就是所谓的紧耦合，不同组的点就之间是疏耦合。
这就是“疏耦合原理”。一个程序可以被拆分成几个不同的部分，通常是层级。各部分/层级与其内部结构的逻辑关系紧密，而与其他层级/部分的关系则比较微弱。层级间的交互通常高度区分。1 个层级可以利用其类的子集合来调用另一个层级。
“和‘劳动力分配’原理相同，但范围更广一些？”
“正是。这让我们可以重组部门，让它更高效，甚至是雇佣更多的人才。如果我们不改变相互依赖的协议，所有变更都只是局部的。没有人会受到限制。我们不需要重新改造整个系统。如果部门交互的机制选定合宜，每个部门都可以优化它的内部事务。”
“那是选的好，那如果选的不好呢？”
‘那就要看看有没有改动的余地，和重写整个系统的必要性。这时不时会发生。我们无法预测未来，但是我们可以尽量减少我们重写程序的次数。”
“好的。我明白这个拆分程序的优势，但是它和 OOP 有什么关系呢？
“在选择如何组建部门以及它们之间相互交互时，我们应用了‘抽象原理’。在编程里，抽象被用来决定什么是拆分程序的最佳方法，以及各部分之间如何交互。此原理还可以重复应用于程序的各个组成部分，直到我们把程序拆分成单个的类。”
“隐藏这些部分的内部结构，严格限制它们与其他部分的交互方式，这就是封装，对吗？”
“没错。封装和抽象是 OOP 的基石。好的程序必须符合这两大原理。稍后，我们会讲其他原理，了解它们的优势。”
“太棒了。我已经等不及了！”