模块性： 保持清晰，保持简洁——《unix 编程艺术》学习笔记

软件设计有两种方式：一种是设计的非常简洁，没有看得到的缺陷；另一种设计的极为复杂，有缺陷也看不出来。第一种方式难度要大得多。——C.A.R Hoare

更精练的表达：一种是明显没有缺陷；一种没有明显的缺陷。

要编写复杂软件又不至于一败涂地的唯一方法，就是用定义清晰的接口把若干简单的模块组合起来。这样一来，多少问题就只出现在局部，可以对局部进行优化和改进而又不至于牵动全身。

本章关注的是进程单元内的模块化。

1.1封装和最佳模块大小

模块化原则的内容：模块化代码的首要特质是封装。封装良好的模块不会过多的向外部披露自身的实现细节，不允许其他模块调用自身的实现代码，也不调用其他模块的实现代码，不会胡乱的共享全局数据。模块间通信通过应用程序编程接口（API）——一组严密，定义良好的函数调用和数据结构通信。

API是描述程序整体结构的重要部分，体现了模块间的通信。它定义了整个体系。

如何验证API是否设计良好？看你是否能对他表达清楚。

好的实践是，先定义接口，在实现接口。

缺陷的密度和模块大小的关系：

模块的逻辑行数成U字形分布，也就是，模块很大或者很小，缺陷的密度都很大。合理的逻辑函数在200—400之间。考虑到空行或注释，一个模块的合理大小约是400~800行。但是这只是一个参考。

原因是，模块越小，程序划分的模块越多，程序整体的复杂度在模块间交互上会很大。

模块越大，则一个模块内的复杂度越大。

另外，从系统的角度来考虑，首先应该对系统分层；分层之后，在每个层次，又可以分为多个协作的进程；每个进程内，又可以分为多个交互的模块。