设计模式与软件架构设计

发布时间：2024-03-14 11:58:45 来源：互联网

.

一、面向对象软件架构设计思想 a)面向对象范式 i 面向对象范式的核心是“对象”的概念 ii 所有的东西都聚焦于对象

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

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)时序图将操作分配给类

三、设计模式的本质论

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

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

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

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

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

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

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

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

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

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

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

iv.程序结构复杂：设计模式关注的是如何使软件更具可维护性，因此从结构上已经与原始的需求完全不同。加上很多功能是通过对象的动态组合实现的，程序的动态结构变得与静态结构同样重要。从单纯的静态结构(例如类图)已经很难理解实现的方式和最终的意图了，这也是经常是使用设计模式的代价之一。

c)设计模式不能做什么

i.设计模式不是法则

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

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

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

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

iii.不是万能的

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

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

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

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

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

?(4)继承层次过多。

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

四、设计模式与架构模式