搜索
1©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide1设计模式与软件架构设计©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide2议题（1）面向对象软件架构设计思想（2）使用UML进行软件架构设计（3）设计模式的本质论（4）设计模式与架构模式2©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide3面向对象本质论—面向对象范式©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide4议题z功能分解模式分析z功能分解模式如何适应需求的变化z责任转移模式处理需求的变化z面向对象范式3©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide5问题的描述z编写代码访问存储在数据库中的几何形状的描述，再把得到的几何形状显示出来。©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide6解决问题步骤z在数据库中查找几何形状的列表；z打开形状列表；z以某种规则将这个列表排序；z在显示器上显示单个的几何形状；•识别形状的具体类型•获得形状的位置•调用适当的函数，并传递形状的位置给它，来显示这个形状4©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide7功能分解z分析者将问题拆分成多个功能步骤，这些步骤组合起来就可以解决实际的问题。z把问题分解成小块来解决，比一次处理整个问题要简单。©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide8功能分解带来的问题z它不能帮助我们为未来可能发生的变化作准备。z它不能把帮助我们的代码优雅的演变。z变化的发生还为错误和意外结果的发生创造了机会-许多错误都来自于代码的变化。5©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide9模块化方式处理变化z模块化可以帮助你写出更容易理解的代码，更容易理解的代码也更容易维护；z模块化并不能帮助你写出能应付所有可能出现的变化代码©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide10内聚和耦合z内聚度：是指程序中的操作之间联系紧密的程度。描述了一个子程序的内部成分之间相互联系的强度。z耦合度：是指两个子程序联系的强度。描述了一个子程序与其他子程序之间的联系强度。z耦合度与内聚度成反比。z目标：蒋建具有内部完整性（强内聚）的子程序，以及小的、直接的、可见的、灵活的与其他子程序之间的联系（松耦合）6©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide11责任转移模式处理需求变化z实际问题的描述：TechED2005大会上，我主讲了ReportBuilder,当参加会议的听众听完我的演讲后，需要到其他的分会场去参加其他的技术演讲，我的一种做法是：•获得参加会议的听众的人名单；•对于名单上的每个人：•查找他的下一技术演讲的题目；•查找他的下一参会的地点；•查找到他下一分会场的路径；•告诉他怎样去下一个地点。©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide12不同实现方案z为了实现上述的过程，可能需要：•获得本会场上人的名单的方法。•获得每个人的日程安排表的方法。•一个程序来告诉某个人如何从我的分会场到达另外一个分会场。•一个控制程序来为每一个人做需要的步骤。z另外实现的方案：•把从本会场到其他会场的路径张贴出来•告诉所有的参会者按照张贴的路径到下一个分会场。7©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide13揭示问题的本质z第一种方法，对每个人都指明确地指出路径，必须注意许多细节，除了你之外的任何人对任何事情都没有责任。z用第二种方法，你给出了一个普遍的指令，并期望每个人都能自己知道如何完成你给出的任务。z对比：第一种方案中你对所有事情负责，而第二种方案参会者对他们自己的行为负责；组织方式的巨大差异。©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide14软件开发过程的视角z概念（conceptual）•展示了问题领域中的概念；•一个概念模型可以在对实现软件有很少或毫无注意的情况下勾勒出来。z规格（Specification）•我们只看软件的接口，而不看软件的实现。z实现（implementation）•置身于代码当中，使常规视角z目标：•一个层次（概念层次）上通信而在另一个层次（实现层次）上执行；•请求者不知道发生了什么，只知道概念上发生了什么。8©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide15面向对象范式z面向对象范式的核心是“对象”的概念z所有的东西都聚焦于对象z围绕对象-而非函数-组织代码©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide16对象从不同视角观察z概念层：一个对象是一系列责任z规格层：一个对象是一系列可以被其他对象或该对象自己调用的方法z实现层：一个对象是一些代码和数据9©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide17面向对象本质论—设计原则©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide18面向对象的设计目标z可维护性z可复用性10©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide19可维护性z现在存在的问题•过于僵硬•过于脆弱•复用率低•黏度过高©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide20可维护性z设计的目标•可扩展性（Extensibility）•新的功能可以很容易地加入到系统中•灵活性（Flexibility）•允许代码修改平稳地发生，而不会涉及到许多其它模块•可插入性（Plugability）•可以很容易地将一个类抽出去，同时将一个可以很容易地将一个类抽出去，同时将一个有同样接口的类加入进来。11©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide21可复用性z重要性•较高的生产效率•较高的软件质量•恰当使用复用可以改善系统的可维护性z传统的复用•代码的剪贴使用•算法的复用•数据结构的复用©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide22设计原则z“开闭”原则(OCP)z里氏代换原则(LSP)z依赖倒转原则(DIP)z接口隔离原则(ISP)z组合/聚合复用原则(CARP)z迪米特法则(LoD)12©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide23“开闭”原则(OCP)zOpen-ClosedPrinciple(OCP)z定义•Softwareentitiesshouldbeopenforextension,butclosedformodification.•一个软件实体应当对扩展开放，对修改关闭z“抽象化”是OCP的关键©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide24z解释“臣启陛下臣启陛下……降一道招安圣旨……与它籍名在箓……一则不动众劳师，二则收仙有道也”（《西游记》）13©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide25“开闭”原则(OCP)z对可变性的封装原则zPrincipleofEncapsulationofVariation(EVP)•找一个可变的因素把它封装起来•一种可变性不应当散落到代码的很多角落里，而应当被封装在一个对象里•一种可变性不应当与另一种可变性混合在一起©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide26里氏代换原则(LSP)zLiskovSubstitutionPrinciple(LSP)z定义•如果对某一类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型14©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide27里氏代换原则(LSP)z解释•“白马，马也；乘白马，乘马也。骊马，马也；乘骊马，乘马也。”（《墨子·小取》）©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide28里氏代换原则(LSP)z解释•“娣，美人也，爱娣，非爱美人也…”（《墨子·小取》）15©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide29依赖倒转原则(DIP)zDependencyInversionPrinciple(DIP)z要依赖于抽象，不要依赖于具体•抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性的决定，是必然性的体现•具体层次则含有一些次要的，与实现相关的算法和逻辑以及战术性的决定，带有相当大的偶然性©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide30依赖倒转原则(DIP)z表述•Abstractionsshouldnotdependupondetails.Detailsshoulddependuponabstractions.（抽象不应当依赖细节，细节应当依赖抽象）•Programtoaninterface,notaimplementation.（要针对接口编程，而不要针对实现编程）16©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide31接口隔离原则(ISP)zInterfaceSegregationPrinciple(ISP)z从一个客户角度来讲，一个类对另一个类的依赖性应当建立在最小的接口上z原则•角色分割•定制服务©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide32合成/聚合复用原则(CARP)zComposition/AggregationReusePrinciple(CARP)z定义•在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过向这些对象的委派达到复用已有功能的目的z尽量使用合成/聚合，而不是继承17©中国科学院软件所2006SoftwareEngineering,7thedition.Chapter1Slide33类图中的关系z一般化(Generalization)关系z表示类与类之间的继承关系，接口与接口之间的继承关系，类对接口的实现关系©中国科学院软件所2006SoftwareEngineering,7thedition