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

采用面向对象的开发的小项目，究竟有没有做架构分析的必要呢？要回答这个问题，必须要
对什么是架构分析、架构分析有什么作用有了解，书中的6.2节就回答了这两个问题。引书
中架构分析的解释如下：
    “架构分析工作主要是从宏观上考虑一个软件系统应该如何组织。通常，在架构分
    析工作中，我们需要确定一些策略性的设计方针、原则和基本模式，在它们的指导
    下，我们可以高屋建瓴地分析软件系统的宏观结构，认识软件系统由哪些组件构成，
    了解组件之间的接口和协作关系。架构分析的结果对于后续的面向对象设计工作也
    是一种约束，有助于消除设计和实现过程中的随意性。因此，架构分析有时也被称
    做策略设计。”
架构分析的作用，书中说道：
    “架构分析在大多数软件开发过程中都能够发挥极其重要的作用。
    ·首先，现代软件系统越来越复杂，如果没有良好的结构和规则，软件的复杂性可能
    会像混沌学所说的“蝴蝶效应”那样快速膨胀和爆炸，以至于超出常人的理解能力。而
    架构分析工作预先为软件定义了科学的结构和规则。通过这些结构和规则，人们能有
    效地控制软件的复杂性，使软件易于理解、实现和管理。
    ·其次，好的软件架构既可以分离软件中的不同组件，又可以精确定义组件之间的接口
    ，这可以使软件系统中的大部分组件具备良好的可复用性。……
    ·最后，架构分析的结果也是多个项目进行协作的基础。……”
既然架构分析有这么多好处，那这一步的工作看来是不能省的了。在我们进行架构分析的过
程中，应该时刻注意不要走入功能分析的误区，要强调数据和操作之间的封装。与面向对象
分析时一样，架构分析也应根据软件类型和规模的不同，采用不一样的分析方法。在迭代开
发模型里，架构分析可在不同级别，不同层次进行，逐步细化，直到项目组认为组件的粒度
够小，可在开发过程中得到较好的控制为止。

不同类型的软件，对应有不同的架构模式，“架构模式描述了软件系统基本的组织策略。它
提供了一系列预定义的职责明确的子系统，以及组织这些子系统的关系的规则和指南。”根
据FISHGUI项目的特点，分层架构比较适合。采用分层架构，也有需要注意的几点：
     “·层之间要尽量地松散，依赖于接口，而不是具体实现；
     ·级别相同、职责类似的元素应该被组织到同一层中；
     ·复杂的模块应该被继续分解为粒度更细的子系统；
     ·把可能变化的元素封装到一个层中，这样，变化时，只有受影响的层需要改变；
     ·上层只调用下一层提供的服务，而不能跨层调用，但对限制不是太严格的小系统，
     也可以灵活处理；
     ·下层不能调用上层提供的功能服务，也就是说，不能造成层与层之间的双向依赖或
     循环引用。
要避免循环依赖，可以参考Uncle bob写的文章。  

接着，书中以FISHGUIDemo为例，介绍了应用层的MVC架构模式，还有对分层进行细化的子系
统设计。

“子系统设计属于面向对象设计的范畴，是在面向对象分析工作结束之后进行的。对于那些相
对独立却又比较复杂、不能用一个类来概括的分析类，我们可以把它们定义为一个子系统，
同时精确地定义子系统的接口。子系统通过接口与其他的类和对象协同工作，实现整个系统
功能。当子系统的接口明确后，子系统内部的实现细节就不会妨碍子系统与其他类和对象的
交互了。因此，子系统设计是对系统架构的进一步细化，是对架构中的特定层次进行的更为
精密的划分。”

也要知道的是，子系统与层和包之间是有区别的。定义子系统也不是一定的，要根据实际需
要。用接口替代子系统绘制顺序图时，接口不能再向其他对象发送任何消息，因为接口只是
一个子系统向外提供的所有行为的抽象，其中不能包括任何具体的实现代码，我们不能对子
系统的实现细节做任何假设。否则更改实现时，就会破坏接口的稳定性。