【代码阅读的方法与实践】第9章 系统构架

第9章 系统构架

一个系统可以（在重大的系统中也确定如此）同时展示出多种不同的构架类型。以不同的方式检查同一系统、分析系统的不同部分、或使用不同级别的分解，都有可能发现不同的构架类型。
协同式的应用程序，或者需要协同访问共享信息或资源的半自治进程，一般会采用集中式储存库构架。
黑板系统使用集中式的储存库，存储非结构化的键/值对，作为大量不同代码元件之间的通信集线器。
当处理过程可以建模、设计和实现成一系列的数据变换时，常常会使用数据流（或管道--过滤器）构架。
在批量进行自动数据处理的环境中，经常会采用数据流构架，在对数据变换工具提供大量支持的平台上尤其如此。
数据流构架的一个明显征兆是：程序中使用临时文件或流水线（pipeline）在不同进程间进行通信。
使用图示来建模面向对象构架中类的关系。
可以将源代码输入到建模工具中，逆向推导出系统的构架。
拥有大量同级子系统的系统，常常按照分层构架进程组织。
分层构架一般通过拥有标准化接口的软件组件来实现。
系统中每个层可以将下面的层看作抽象实体，并且（只要该层满足它的需求说明）不关心上面的层如何使用它。
层的接口既然可以是支持特定概念的互补函数族，也可以是一系列支持同一抽象接口不同底层实现的可一互换函数。
用C语言实现的系统，常常用函数指针的数组，表达层接口的多路复用操作。
用面向对象的语言实现的系统，使用虚方法调用直接表达对层接口的多路复用操作。
系统可以使用不同的、独特的层次分解模型跨各种坐标轴进行组织。
使用程序切片技术，可以将程序中数据和控制之间依赖关系集中到一起。
在并发系统中，一个单独的系统组件起到集中式管理器的作用，负责启动、停止和协调其他系统进程和任务的执行。
现实的系统都会博采众家之长。当处理此类系统时，不要徒劳地寻找无所不包的构架图；应该将不同构架风格作为独立但相关的实体来进行定位、并了解。
状态变迁图常常有助于理清状态机的动作。
在处理大量的代码时，了解将代码分解成单独单元的机制极为重要。
大多数情况下，模块的物理边界是单个文件、组织到一个目录中的多个文件或拥有统一前缀的文件的集合。
C中的模块，由提供模块公开接口的头文件和提供对应实现的源文件组成。
对象的构造函数经常用来分配与对象相关的资源，并初始化对象的状态。函数一般用来释放对象在生命期中占用的资源。
对象方法经常使用类字段来存储控制所有方法运行的数据（比如查找表或字典）或维护类动作的状态信息（例如，赋给每个惟一标识符的计数器）。
在设计良好的类中，所有的字段都应声明为private，并用公开的访问方法提供对它们的访问。
在遇到friend方法时，要停下来分析一下，看看绕过类封装在设计上的理由。
可以有节制地用运算符增强特定类的可用性，但用运算符重载，将类实现为拥有内建算术类型相关的全部功能的类数字实体，是不恰当的。
泛型实现不是在编译期间通过宏替换或语言所支持的功能（比如C++模板和Ada的泛性包）来实现，就是在运行期间通过使用数据元素的指针和函数的指针、或对象的多态性来实现。
抽象数据类型经常用来封装常用的数据组织方案（比如树、列表或桟），或者对用户隐藏数据类型的实现细节。
使用库的目标多种多样：重用源代码或目标代码，组织模块集合，组织和优化编译过程，或是用来实现应用程序各种特性的按需载入。
大型的、分布式的系统经常实现为许多互相协作的进程。
对于基于文本的数据储存库，可以通过浏览存储在其中的数据，破译出它的结构。
可以通过查询数据字典中的表，或使用数据库专用的SQL命令，比如show table，来分析关系型数据库的模式。
识别出重要的构架元素后，可以查找其最初的描述，了解正确地使用这种构架的方式，以及可能出现的误用。
要详细分析建立在某种框架之上的应用程序，行动的最佳路线就是从研究框架自身开始。
在阅读向导生成的代码时，不要期望太高，否则您会感到失望。
学习几个基本的设计模式之后，您会发现，您查看代码构架的方式会发生改变：您的视野和词汇将会扩展到能够识别和描述许多通用的形式。
频繁使用的一些模式，但并不显式地指出它们的名称，这是由于构架性设计的重用经常先于模式的形成。
请试着按照底层模式来理解构架，即便代码中并没有明确地提及模式。
大多数解释器都遵循类似的处理构架，围绕一个状态机进行构建，状态机的操作依赖于解释器的当前状态、程序指令和程序状态。
多数情况下，参考构架只是为应用程序域指定一种概念性的结构，具体的实现并非必须遵照这种结构。