第四章——模块性。

模块有两个很重要的特性，紧凑性和正交性。
紧凑性是指小，拥有较少的public method 数量，能一次看到全貌。虽然书中提倡的10个public method 每个模块，但是难于做到，但是15个以下，还是能做到的。
正交性是“每次只作一件事并做好”的学术词。非正交的method的缺陷是副作用，因为在一次过程中实现了两个事情，或者更具体的说，是函数体内实现了函数名说没有说过要做的事情，并且这件事改变了模块的状态。举个手头上的例子：一个物理对象基类(IPhysxObject)有一个函数计算其子几何体的总质量，名称是_computeTotalMass(dMass &mass)。我在遍历所有几何体算出总质量后，把其设置为物理对象的当前质量——这就非正交了，因为多做了一件事：改变对象的质量。如果把函数名改为_updateMass(void)，就没有什么问题。
非正交带来的副作用，虽然说目前熟悉的项目中没问题，但问题是如果你有机会重用这些非正交的模块，你很可能忘却了它带有副作用的地方，或者发现了，却需要额外的代码来抑制副作用。

软件是多层的。在层的设计与实现过程中（自顶向下和自底向上）会出现胶合层。胶合层这个概念很难理解，即使现在仍不能说是理解正确。书上所说是“顶层逻辑和底层原语集阻抗匹配的产物”，软件是通过顶层逻辑加上依赖调用底层原语的函数实现其功能的，那么胶合层是否可以理解为原语调用？那么，所谓的薄胶合，便是从顶层到真正的调用底层原语，其中经历了较少层次的函数调用嵌套。
C被视为薄胶合的语言，我看不出来（缺少根本上的代码量）；但是C++作为厚胶合的典范可是很有感触。厚胶合源于类继承层数，即使只是两层，仍会产生很普遍的麻烦，而且这其中还涉及到基类的变量是protected还是private的问题（我以前比较支持private，认为：如果子类需要使用这些变量的话，可以在基类中添加protected的使用原语，退一步还可以添加accessor）。举手头上的例子：
d1.Touch(d2)，需要访问d2的mpEnt(protected)，即使是同一基类，到了子类中也是非法的。解决的办法如友元，或者是一个public accessor，或者将D1::Touch实现的功能在Base中做一个原语，但是都不太舒服，不是吗？友元者，对于数量庞大的子类间两两友元，需要多少心力呢？public accessor者，成员变量传统上是不public的，即使accessor，如果返回成员的指针或者引用，那和直接public成员又有多少差别呢？原语者，只是把子类的功能提升到基类实现，然后子类在写Touch函数的时候简单的调用原语。太多原语实现存放在基类，使得基类的尺寸庞大，真的好吗？如果子类要实现的功能不仅涉及基类成员，还涉及子类成员，怎样处理？作为原语引用参数传递，还会直观吗？
有点显然的，accessor，或者基类原语，都不断增加胶合的厚度，因为你总是先要call一个只有一行实现的接口——然后才调用真正的实现，而且真正的实现中，肯定还会有其他执行类似与这种厚胶合···
厚胶合的真正缺陷并不在于函数调用效率，即使调用级数再高也不是主要问题。真正的缺陷是代码的透明性——由于胶合过于雄厚，容易忽略某些零碎的细节，bug之地难以发现，或者code review的时候，完全没有办法看清全貌。
与之相比，C所以平坦，可以说是它没有继承（模仿会使得代码更复杂），同时，访问完全是public的。