做外贸的网站主要有哪些,网站分享正能量,wordpress 时区 8小时,开发小程序外包公司第五章 设计模式与软件架构设计 一、面向对象软件架构设计思想 a) 面向对象范式 i. 面向对象范式的核心是“对象”的概念 ii. 所有的东西都聚焦于对象 iii. 围绕对象-而非函数-组织代码 b) 对象从不同视角观察 i. 概念层#xff1a;… 第五章 设计模式与软件架构设计 一、面向对象软件架构设计思想 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模式属于架构模式特别适合应用于分布式应用系统。大型软件的顶层架构往往需要使用多种架构样式。如整个目标软件系统采用分层结构在系统的不同层次内再分别使用适宜的其他类型的架构模式。 转载于:https://www.cnblogs.com/leandro/archive/2009/01/18/1372303.html
