读《Unix编程艺术》 第四章：模块化、保持清晰、保持简洁

第四章： 模块化、保持清晰、保持简洁.

软件设计有两种方式 : 一种是设计得极为简洁，没有看得到的缺陷；另外一种是设计得极为复杂，有缺陷也看不出来，显然，第一种方式的难度要大得多。

模块化的原则：  要编写复杂的软件又不至于一败涂地地唯一方法，就是用定义清晰的接口把若干简单模块组合起来，如此一来，多数问题只会出现在局部，那么还有希望对局部进行改进和优化，而不至于牵动全身.

相对于其他，Unix程序员更加重视模块化、更注重正交性和紧凑性等问题。

封装和最佳模块化大小
  模块化的首要特质是封装。
------- 封装良好的模块不会过多向外部披露自身的细节，不会直接调用其他模块的实现代码，也不会胡乱共享全局数据.

  模块之间通过API和数据结构进行通信.

检测一组API是否设计良好，你可以：
尝试用人类自然语言来描述，是否可以把事情说清楚？

模块分得越彻底，就意味着每一块就越小；
当然，模块化代码也不可过于小；
   模块过小时，几乎所有复杂度都在接口；想要理解任何一段代码前，必须理解全部代码，因此阅读代码非常困难
     Hatton的经验数据表明，200～400之间逻辑行代码是模块设计的"最佳点"

紧凑性和正交性
  紧凑性就是一个设计是否能进入人脑中特性。
   检验一个设计是否紧凑的方法是： 有经验的用户通过需要操作手册吗？ 如果不需要，则设计就是紧凑的。
  紧凑的工具和顺手的自然工具一样： 让人乐于使用，不会在你的想法和工作之间格格不入。

  正交性是有助于使复杂设计也能紧凑的重要特性之一。 既： 每一个动作只改变一件事，不会影响其他。无论是什么系统，改变每个属性的方法只有一个 。
   比如显示器，改变亮度而不会影响对比度。

 
模块式编码
  模块式，模块式，那么改如何做？
  编写代码之前，问问自己以下问题：
  1.有多少全局变量？ 全局变量对于模块化是毒药，很容易使各模块化轻率、胡乱地相互泄漏信息。
  2.单个模块大小是否在Hatton的最佳范围之内？  如果不是，超过就可能产生长期的维护问题。
  3.模块内的单个函数是否太大了？ 这不是一个行数计算问题，而是一个复杂性问题。 如果不能以一句话来简单描述一个函数与其调用程序之间的约定，这个函数可能太大拉。
  4.代码是否有内部API---好的API应是意义清楚，不用看具体如何实现就可理解的，不确定？ 那么你打电话给另外一个程序员描述，如果说不清楚，那么API就可能过于复杂了.
   5.API的入口是不是超过7个？有没有哪个类超过7个方法，数据结构的成员是不是超过7个？
   6.整个项目中每个模块的入口点数量如何分布？是不是均匀？很多入口点的模块真的需要这么多入口点吗? 记住： 模块复杂性往往和入口点数量的平方成正比----这也是简单API优于复杂API的另一个原因.