首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

怎么学习阅读大型项目的代码(9)

怎么学习阅读大型项目的代码(9)

第九章: 系统构架

++++++++++++++

    一个系统可以(在重大的系统中也确实如此)同时出多种不同的构架类型. 以不同的方式检查同一系统|分析系统的不同部分 | 或使用不同级别的分解, 都有可能发现不同的构架类型.

    协同式的应用程序, 或者需要协同访问共享信息或资源的半自治进程, 一般会采用集中式储存库构架.

    黑板系统使用集中式的储存库, 存储非结构化的键/值对, 作为大量不同代码元件之间的通信集线器.

    当处理过程可以建模|设计和实现成一系列的数据变换时, 常常会使用数据流(或管道—过滤器)构架.

    在批量进行自动数据处理的环境中, 经常会采用数据流构架, 在对数据工具提供大量支持的平台上尤其如此.

    **数据流构架的一个明显征兆是: 程序中使用临时文件或流水线(pipeline)在不同进程间进行通信. **

    使用图示来建模面向对象构架中类的关系.

    可以将源代码输入到建模工具中, 逆向推导出系统的构架.

    拥有大量同级子系统的系统, 常常按照分层构架进行组织.

    分层构架一般通过堆叠拥有标准化接口的软件组件来实现.

    系统中每个层可以将下面的层看作抽象实体, 并且(只要该层满足它的需求说明)不关心上面的层如何使用它.

    层的接口既可以是支持特定概念的互补函数族, 也可以是一系列支持同一抽象接口不同底层实现的可互换函数.

    用C语言实现的系统, 常常用函数指针的数组, 表达层接口的多路复用操作.

    用面向对象的语言实现的系统, 使用虚方法调用直接表达对层接口的多嘴复用操作.

    系统可以使用不同的|独特的层次分解模型跨各种坐标轴进行组织.

    使用程序切片技术, 可以将程序中的数据和控制之间依赖关系集中到一起.

    在并发系统中, 一个单独的系统组件起到集中式管理器的作用, 负责启动|停止和协调其他系统进程和任务的执行.

    许多现实的系统都会博采众家之长. 当处理此类系统时, 不要徒劳地寻找无所不包的构架图; 应该将不同构架风格作为独立但相关的实体来进行定位|识别并了解.

    状态变迁图常常有助于理清状态机的动作.

    在处理大量的代码时, 了解将代码分解成单独单元的机制极为重要.

    大多数情况下, 模块的物理边界是单个文件|组织到一个目录中的多个文件或拥有统一前缀的文件的集合.

    C中的模块, 由提供模块公开接口的头文件和提供对应实现的源文件组成.

    对象的构造函数经常用来分配与对象相关的资源, 并初始化对象的状态. 函数一般用来释放对象在生命期中占用的资源.

    对象方法经常使用类字段来存储控制所有方法运作的数据(比如查找表或字典)或维护类运作的状态信息(例如, 赋给每个对象一个标识符的计数器).

    在设计良好的类中, 所有的字段都应在声明为private, 并用公开的访问方法提供对它们的访问.

    在遇到friend声明时, 要停下来分析一下, 看看绕过类封装在设计上的理由.

    可以有节制地用运算符增强特定类的可用性, 但用运算符重载, 将类实现为拥有内建算术类型相关的全部功能的类实体, 是不恰当的.

    泛型实现不是在编译期间通过宏替换或语言所支持的功能(比如C++模板和Ada的泛型包)来实现, 就是在运行期间通过使用数据元素的指针和函数的指针|或对象的多态性实现.

    抽象数据类型经常用来封装常用的数据组织方案(比如树|列表或栈), 或者对用户隐藏数据类型的实现细节.

    使用库的目的多种多样: 重用源代码或目标代码, 组织模块集合, 组织和优化编译过程, 或是用来实现应用程序各种特性的按需载入.

    大型的|分布式的系统经常实现为许多互相协作的进程.

    对于基于文本的数据储存库, 可以通过浏览存储在其中的数据, 破译出它的结构.

    可以通过查询数据字典中的表, 或使用数据库专有的SQL命令, 比如show table, 来分析关系型数据库的模式.

    识别出重用的构架元素后, 可以查找其最初的描述, 了解正确地使用这种构架的方式, 以及可能出现的误用.

    要详细分析建立在某种框架之上的应用程序, 行动的最佳路线就是从研究框架自身开始.

    在阅读向导生成的代码时, 不要期望太高, 否则您会感到失望.

    学习几个基本的设计模式之后, 您会发现, 您查看代码构架的方式会发生改变: 您的视野和词汇将会扩展到能够识别和描述许多通用的形式.

    频繁使用的一些模式, 但并不显式地指出它们的名称, 这是由于构架性设计的重用经常先于模式的形成.

    请试着按照底层模式来理解构架, 即使代码中并没有明确地提及模式.

    大多数解释器都遵循类似的处理构架, 围绕一个状态机进行构建, 状态机的操作依赖于解释器的当前状态|程序指令和程序状态.

    多数情况下, 参考构架只是为应用程序域指定一种概念性的结构, 具体的实现并非必须遵照这种结构.
返回列表