Design in Construction
我们要学会使类与类之间、子程序与子程序之间保持松散耦合，就是使一个类或者子程序能够很容易地被另一者调用。在结对编程的对接过程中，作为ui组我们就需要调用core组写的计算核心，这就是两个保持松散耦合的模块。我们只需要知道传入参数的设置就可以实现调用。当然，传的参数越少越好。另一方面，如果两个类都依赖于对方对同一个全局变量的使用情况，那么它们之间的耦合关系就变得紧密了。我想，这也是全局变量能不用则不用的原因之一。简而言之，耦合关系要清晰明了，要做到在使用一个模块的时候尽量少地需要去关注其他模块的工作方式。
用一种设计方案来解决问题会为你带来一些新的洞察力，从而帮助你使用另一种更好的设计来解决问题。这有点像高中的时候写作文，通常你想到的第一个立意不是最好的，但它会为你打开思路，使你迸发出更多思想的火花。读到这里，才真正开始明白设计的启发式方法中的“启发”二字。不要停留于你所想到的第一套解决方案，而是去寻求合作，探求简洁性，在需要的时候建立试验性原型，迭代，再迭代。通常最大的失误不是设计做得不好，而是设计做得不够。多永远比不足要好。
Working Classes
“类”并不是单纯地把稍微有一点关系的数据和子程序堆在一块儿，相反，它其中的数据和程序具有很强的内聚性，使你在编写其他部分代码的时候，可以安全地忽视它。而我们在数据结构课程中所接触到的抽象数据类型ADT构成了“类”的基础。要使“类”的内部具有强内聚性，与作者提到的“一致的抽象”有很大的关系，在我的理解中，就如同在一个ADT中，我们不能既有对线性表的操作，又有对树的操作。类也是如此，在类的内部，数据与子程序之间要有很强的关联，使这个类的职能更加专一。
关于封装的概念，在上周的读书笔记中也提到过一点。一个良好的封装需要注意很多点，这里简单谈一谈对其中理解略深的两点。一是不要公开暴露成员数据，就是说不要让调用方可以自由地修改一个类里面的数据。另一点，不要对类的使用者作出任何假设。在定义接口时，不要给调用方设太多的限制和约束，从而方便自己。比如在结对编程中，core应该全面地判断输入的非法性，考虑各种情况，而不是限制用户的输入。
对继承虽然了解一些，但理解得并不够深入，看了讲述继承的原则的这一节，给我的总体认识是使用继承的前提要求非常高，如果使用得不好，往往与初衷背道而驰。所以包含关系比继承关系更为可取。我觉得积累更多的技术以后再来看这本书的收获一定会更多。