读书笔记《道法自然--面向对象实践指南》第三章

掌握了系统的需求后，FISHGUI项目组像其它许多的项目组一样，想直接进入设计阶段。谨
慎稳重的老Z提出：在进行设计之前，应该考虑将要采用的设计方法和开发过程遵循的生命
周期模型。这个提议并不是毫无意义的，老Z的提议所根据的是这样一个原则：没有哪种设
计方法适应于所有的场合，我们应该根据具体的情况，选择合适的设计方法。这原则在语言
优劣的争论上同样的适用，并没有哪种语言绝对好于另一种，作为程序员，我们应该根据具
体的情况选择适用的工具。由于FISHGUI项目是一个框架系统，需要具备可复用、可扩展和
易维护等特性，而用面向过程的方法分析得出的FISHGUI结构中，有许多的不足：

第一，含有大量的全局变量，不利于管理；
第二，函数之间的依赖(即耦合)非常大；
第三，大量的回调函数很难管理。这些缺点显然使得面向过程的方法不适于FISHGUI项目。

大量全局变量、函数过多的依赖、大量回调函数为什么是缺陷呢？区分软件的好坏，除了要
断定软件是否实现了功能性需求外，还有如下几个标准：

可读性：设计是否易于理解。好理解的就容易维护。
可复用性：架构、模块、函数或过程、类、组件等是否容易被复用。
可扩展：需求变化是，扩展的难易程度。
可维护性：维护的难易程度(bug fix、遗漏功能添加等)的难易程度

这些衡量标准也许比较抽象，不好理解，其实也可以用软件的内聚度和耦合度来衡量。

内聚度：表示一个模块、类或函数所承担职责的自相关程度。如果一个模块只负责一件
事情，就说明这个模块有很高的内聚度；如果一个模块负责很多毫不相关的事情，则内
聚度很低。内聚度高的易于复用、扩展和维护。

耦合度：表示模块和模块之间、类和类之间、函数和函数之间的亲密程度。耦合度越高
，依赖性就越强，软件的可维护性、可扩展性和可复用性就越低。如果两个函数都访问
同一个全局变量，则它们同时依赖于这一变量。

高内聚、低耦合，就是我们的目标。

采用面向对象的设计方法，必须遵循一些原则，才能得到好的设计，书中列举了几个比较重
要的原则，主要包括：

开闭原则：模块对扩展应是开发的，对修改应是关闭的。
完全替换原则：派生类应该完全能够替换掉基类。
依赖倒置原则：依赖于抽象，而不要依赖于具象。
非循环依赖原则：包和包之间不能有循环依赖关系。
只实现真正需要的，不做你认为需要的。
不要重复自己：任何代码都只出现一次。
保持简化的设计。
为人写代码，而不是为机器写代码。

上面的几个原则，大部分可以在Uncle Bob的《敏捷软件开发——原则、模式与实践》一书中
找到更详细的解释。

面向对象的开发过程主要包括面向对象分析、架构分析、面向对象设计、编码和测试等几个
阶段。3.6章介绍了软件生命周期模型的选择问题，软件生命周期模型反映了软件开发过程
中各开发阶段的主旨方式，描述了软件开发的基本流程和模式。主要列举了瀑布模型和迭代
模型两种，并指出迭代模型更适合于面向对象的开发过程。

附录：(The Principles of OOD)
SRP The Single Responsibility Principle
OCP The Open Closed Principle
LSP The Liskov Substitution Principle
DIP The Dependency Inversion Principle
ISP The Interface Segregation Principle

REP The Release Reuse Equivalency Principle
CCP The Common Closure Principle
CRP The Common Reuse Principle

ADP The Acyclic Dependencies Principle
SDP The Stable Dependencies Principle
SAP The Stable Abstractions Principle