《高级软件架构师讲义》学习笔记5

 第五章     设计模式与软件架构设计

 

一、面向对象软件架构设计思想

a)         面向对象范式

                           i.      面向对象范式的核心是“对象”的概念

                         ii.      所有的东西都聚焦于对象

                        iii.      围绕对象-而非函数-组织代码

b)        对象从不同视角观察

                         i.        概念层：一个对象是一系列责任

                       ii.        规格层：一个对象是一系列可以被其他对象或该对象自己调用的方法

                      iii.        实现层：一个对象是一些代码和数据

c)        设计原则

                         i.        “开闭”原则(OCP)

                       ii.        里氏代换原则(LSP)

                      iii.        依赖倒转原则(DIP)

                     iv.        接口隔离原则(ISP)

                       v.        组合/聚合复用原则(CARP)

                     vi.        迪米特法则(LoD)

二、使用UML进行软件架构设计

a)         最小UML建模技术

                         i.        对于大多数问题而言，只需使用20%的UML，就可以完成80%的建模工作。

                       ii.        实际中，好像总是没有足够的时间来完成建模、分析和设计工作，总是过早地进入到编码阶段。

                      iii.        足以很好地完成软件项目工作所需的、最小的UML和建模技术子集。

b)        类图规定了代码的结构

c)        时序图将操作分配给类

d)         

三、设计模式的本质论

a)         模式是从解决具体问题抽象出来的，这种具体问题在特定的上下文中重复出现。也就是说，每个具体形式都对一种重复的问题采用重复的解决方案。

b)        理解设计模式的结果和代价

                         i.              对象过多：设计模式的精髓之一是将可变部分封装为对象，带来的好处是系统更加灵活，易于维护，但也大量增加了对象。如果不恰当地使用设计模式，会使系统难以调试。

1.         命令模式：将行为封装为对象，这样原来一个对象中的若干方法变成了若干命令对象。如果将命令模式应用在一个GUI用户界面上，每一个菜单项就要生成一个命令对象，原来由一个对象完成的工作现在可能需要十几个对象来完成。

2.         状态模式：将不同的状态封装为对象，原来可能是通过判断语句完成的工作分散到各个对象中完成。由于状态是动态决定的，因此在设计测试用例时有难度。

                       ii.              更复杂的装配关系：很多设计模式依赖对象之间的关系，因此在初始化时需要执行相应的装配工作，需要装配对象的模式有如下几种。

1.         生成器模式：需要装配生成器和导航器。

2.         桥接模式：需要将代表逻辑的对象和代表实现的对象进行装配。

3.         观察者模式：需要将不同的观察者对象关联在一起。

4.         职责链模式：需要组装整条职责链。

                      iii.              测试难度加大：这是前面两个结果导致的，由于对象的增多和对象间关系的复杂，因此测试用例的设计难度增大。特别是很多逻辑上的错误可能由装配关系不当造成，并且在编译时很难发现。解决测试难度大的方法是将测试用例文档化，即绘制测试用例的对象图。这个话题超出了本书的范围，有兴趣的读者可参考相关书籍。

                     iv.              程序结构复杂：设计模式关注的是如何使软件更具可维护性，因此从结构上已经与原始的需求完全不同。加上很多功能是通过对象的动态组合实现的，程序的动态结构变得与静态结

                       v.              构同样重要。从单纯的静态结构(例如类图)已经很难理解实现的方式和最终的意图了，这也是经常是使用设计模式的代价之一。

c)        设计模式不能做什么

                         i.              设计模式不是法则

模式理论的精髓之一就是模式的使用是有前提和代价的，模式是在某种前提下，综合各方面因素后考虑得出的结果。即在使用模式时总是要付出一定的代价，当然这种代价是可以接受的。如果某个模式在所有场合中的使用都是必然的，那么它就不能叫做模式了，而是一种必

须遵守的法则。例如“面向接口，而非实现编程”，是法则而非模式。

                       ii.              不能提高开发速度或者形象开发速度

􀁺 如果以一个开发周期作为考核标准，恐怕没有人会使用设计模式。设计模式并不能提高目前的开发速度，至少其关注的目标并不是开发速度。很多情况下甚至会降低开发速度，即使是正确地选择了设计模式。

􀁺 这是因为设计模式可能会引入更多的对象和更复杂的对象装配关系，从而使得程序有更多的动态状态，从局部看来变得结构复杂，难以理解并且测试困难。如果仅仅关注于形象进度，或者能够百分之百地确定需求没有变化，那么设计模式并不是很好的选择。

                      iii.              不是万能的

􀁺设计模式的使用是自然而然的事情，很多情况下不使用设计模式是因为不需要，问题还没有复杂到非用不可的程度。我们是为了设计而使用设计模式，而不是为了使用设计模式而设计。

􀁺 当你的项目发现有如下问题之一时，就需要考虑重构代码，可能会有某种模式适合。

• (1)代码无法进行单元测试。

• (2)需求的变动总是导致代码的变动。

• (3)有重复代码存在。

• (4)继承层次过多。

• (5)隐藏的依赖过多。

四、设计模式与架构模式

a)         主要架构模式

                         i.              流程处理模式

                       ii.              客户/服务器模式、

                      iii.              模型—视图—控制器模式(MVC)

                     iv.              分层模式

b)        确立软件架构考虑的因素

                         i.              架构中包的数量

                       ii.              架构中包之间的耦合度

                      iii.              软件元素的稳定性

                     iv.              软件元素的分类

                       v.              作为软件系统运行环境的物理网络拓朴

                     vi.              软件元素的安全、保密级别

                    vii.              开发团队的技术专长

                  viii.              调整软件架构，支持并行开发

看了这里之后才了解MVC模式与GOF那些设计模式有什么区别，
MVC模式属于架构模式，特别适合应用于分布式应用系统。
大型软件的顶层架构往往需要使用多种架构样式。如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他类型的架构模式。