|
第五章设计模式与软件架构设计 一、面向对象软件架构设计思想 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)隐藏的依赖过多。 四、设计模式与架构模式 a)主要架构模式 i.流程处理模式 ii.客户/服务器模式、 iii.模型—视图—控制器模式(MVC) iv.分层模式 b)确立软件架构考虑的因素 i.架构中包的数量 ii.架构中包之间的耦合度 iii.软件元素的稳定性软件开发网 iv.软件元素的分类 v.作为软件系统运行环境的物理网络拓朴 vi.软件元素的安全、保密级别 vii.开发团队的技术专长 viii.调整软件架构，支持并行开发 看了这里之后才了解MVC模式与GOF那些设计模式有什么区别， MVC模式属于架构模式，特别适合应用于分布式应用系统。 大型软件的顶层架构往往需要使用多种架构样式。如，整个目标软件系统采用分层结构，在系统的不同层次内再分别使用适宜的其他类型的架构模式。 |
|
|
