您好,欢迎访问三七文档
软件设计模式与体系结构推荐书籍面向对象设计原则概述面向对象设计原则简介常用的面向对象设计原则包括7个,这些原则并不是孤立存在的,它们相互依赖,相互补充。设计原则名称设计原则简介重要性单一职责原则(SingleResponsibilityPrinciple,SRP)类的职责要单一,不能将太多的职责放在一个类中★★★★☆开闭原则(Open-ClosedPrinciple,OCP)软件实体对扩展是开放的,但对修改是关闭的,即在不修改一个软件实体的基础上去扩展其功能★★★★★里氏代换原则(LiskovSubstitutionPrinciple,LSP)在软件系统中,一个可以接受基类对象的地方必然可以接受一个子类对象★★★★☆依赖倒转原则(DependencyInversionPrinciple,DIP)要针对抽象层编程,而不要针对具体类编程★★★★★接口隔离原则(InterfaceSegregationPrinciple,ISP)使用多个专门的接口来取代一个统一的接口★★☆☆☆合成复用原则(CompositeReusePrinciple,CRP)在系统中应该尽量多使用组合和聚合关联关系,尽量少使用甚至不使用继承关系★★★★☆迪米特法则(LawofDemeter,LoD)一个软件实体对其他实体的引用越少越好,或者说如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,而是通过引入一个第三者发生间接交互★★★☆☆单一职责原则单一职责原则定义单一职责原则(SingleResponsibilityPrinciple,SRP)定义如下:•一个对象应该只包含单一的职责,并且该职责被完整地封装在一个类中。其英文定义为:•Everyobjectshouldhaveasingleresponsibility,andthatresponsibilityshouldbeentirelyencapsulatedbytheclass.另一种定义方式如下:•就一个类而言,应该仅有一个引起它变化的原因。其英文定义为:•Thereshouldneverbemorethanonereasonforaclasstochange.在Form1中写了很多功能?单一职责原则单一职责原则分析一个类(或者大到模块,小到方法)承担的职责越多,它被复用的可能性越小,而且如果一个类承担的职责过多,就相当于将这些职责耦合在一起,当其中一个职责变化时,可能会影响其他职责的运作。类的职责主要包括两个方面:数据职责和行为职责,数据职责通过其属性来体现,而行为职责通过其方法来体现。单一职责原则是实现高内聚、低耦合的指导方针,在很多代码重构手法中都能找到它的存在,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。单一职责原则单一职责原则实例实例说明•某基于Java的C/S系统的“登录功能”通过如下登录类(Login)实现:•现使用单一职责原则对其进行重构。单一职责原则单一职责原则实例实例解析开闭原则开闭原则定义开闭原则(Open-ClosedPrinciple,OCP)定义如下:•一个软件实体应当对扩展开放,对修改关闭。也就是说在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,即实现在不修改源代码的情况下改变这个模块的行为。其英文定义为:•Softwareentitiesshouldbeopenforextension,butclosedformodification.开闭原则开闭原则分析开闭原则由BertrandMeyer于1988年提出,它是面向对象设计中最重要的原则之一。在开闭原则的定义中,软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类。开闭原则开闭原则分析抽象化是开闭原则的关键。开闭原则还可以通过一个更加具体的“对可变性封装原则”来描述,对可变性封装原则(PrincipleofEncapsulationofVariation,EVP)要求找到系统的可变因素并将其封装起来。需求不断变化,使系统在不断变化中保持稳定,多扩展,少修改。利用抽象,隔离变化。面向对象的核心将频繁变化的部分抽象拒绝不成熟的抽象开闭原则开闭原则实例实例说明•某图形界面系统提供了各种不同形状的按钮,客户端代码可针对这些按钮进行编程,用户可能会改变需求要求使用不同的按钮,原始设计方案如图所示:•现对该系统进行重构,使之满足开闭原则的要求。LoginForm-button:CircleButton+display():voidCircleButton+view():voidLoginForm-button:RectangleButton+display():voidRectangleButton+view():void变化开闭原则开闭原则实例实例解析很多软件设计模式,就是为了更好的体现(实现)开闭原则。依赖倒转原则依赖倒转原则定义依赖倒转原则(DependenceInversionPrinciple,DIP)的定义如下:•高层模块不应该依赖低层模块,它们都应该依赖抽象。•抽象不应该依赖于细节,细节应该依赖于抽象。其英文定义为:•Highlevelmodulesshouldnotdependuponlowlevelmodules,bothshoulddependuponabstractions.Abstractionsshouldnotdependupondetails,detailsshoulddependuponabstractions.另一种表述为:•要针对接口编程,不要针对实现编程。其英文定义为:•Programtoaninterface,notanimplementation.电脑中各个配件的关系?依赖倒转原则依赖倒转原则分析简单来说,依赖倒转原则就是指:代码要依赖于抽象的类,而不要依赖于具体的类;要针对接口或抽象类编程,而不是针对具体类编程。实现开闭原则的关键是抽象化,并且从抽象化导出具体化实现,如果说开闭原则是面向对象设计的目标的话,那么依赖倒转原则就是面向对象设计的主要手段。所有依赖关系,均应终止于抽象类或者接口依赖倒转原则依赖倒转原则实例:数据库访问:高层模块调用低层程序包(高层依赖于低层)每次更换不同数据库时,高层模块也要做出更改(不能复用高层模块)但高层模块的业务逻辑却改变不大。依赖倒转原则依赖倒转原则分析(如何实现依赖倒转?)类之间的耦合•零耦合关系•具体耦合关系•抽象耦合关系依赖倒转原则要求客户端依赖于抽象耦合,以抽象方式耦合是依赖倒转原则的关键。里氏代换原则里氏代换原则里氏代换原则定义更容易理解的定义方式:•所有引用基类(父类)的地方必须能透明地使用其子类的对象。•或者:把所有的父类,全部替换为子类,则软件行为没有变化其英文定义为:•Functionsthatusepointersorreferencestobaseclassesmustbeabletouseobjectsofderivedclasseswithoutknowingit.只有子类可替换掉父类,父类才可真正被复用依赖倒置原则的根本里氏代换原则里氏代换原则分析里氏代换原则是实现开闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象,因此在程序中尽量使用基类类型来对对象进行定义。而在运行时再确定其子类类型,用子类对象来替换父类对象。子类可替换性,使得使用父类的模块,不修改实现扩展。(引用不同的子类对象)依赖倒转原则依赖倒转原则分析依赖注入•构造注入(ConstructorInjection):通过构造函数注入实例变量。•设值注入(SetterInjection):通过Setter方法注入实例变量。•接口注入(InterfaceInjection):通过接口方法注入实例变量。依赖倒转原则依赖倒转原则实例实例说明•某系统提供一个数据转换模块,可以将来自不同数据源的数据转换成多种格式,如可以转换来自数据库的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource),转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。依赖倒转原则依赖倒转原则实例实例说明•由于需求的变化,该系统可能需要增加新的数据源或者新的文件格式,每增加一个新的类型的数据源或者新的类型的文件格式,客户类MainClass都需要修改源代码,以便使用新的类,但违背了开闭原则。现使用依赖倒转原则对其进行重构。依赖倒转原则依赖倒转原则实例实例解析设计模式的诞生与发展模式的诞生与定义模式起源于建筑业而非软件业模式(Pattern)之父——美国加利佛尼亚大学环境结构中心研究所所长ChristopherAlexander博士《APatternLanguage:Towns,Buildings,Construction》——253个建筑和城市规划模式模式•Context(模式可适用的前提条件)•Theme或Problem(在特定条件下要解决的目标问题)•Solution(对目标问题求解过程中各种物理关系的记述)设计模式的诞生与发展模式的诞生与定义Alexander给出了关于模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再重复相同的工作。Apatternisasolutiontoaprobleminacontext模式是在特定环境中解决问题的一种方案设计模式的诞生与发展软件模式1990年,软件工程界开始关注ChristopherAlexander等在这一住宅、公共建筑与城市规划领域的重大突破,最早将该模式的思想引入软件工程方法学的是1991-1992年以“四人组(GangofFour,GoF,分别是ErichGamma,RichardHelm,RalphJohnson和JohnVlissides)”自称的四位著名软件工程学者,他们在1994年归纳发表了23种在软件开发中使用频率较高的设计模式,旨在用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟。设计模式的诞生与发展软件模式软件模式是将模式的一般概念应用于软件开发领域,即软件开发的总体指导思路或参照样板。软件模式并非仅限于设计模式,还包括架构模式、分析模式和过程模式等,实际上,在软件生存期的每一个阶段都存在着一些被认同的模式。软件模式可以认为是对软件开发这一特定“问题”的“解法”的某种统一表示,它和Alexander所描述的模式定义完全相同,即软件模式等于一定条件下的出现的问题以及解法。软件模式的基础结构由4个部分构成:问题描述、前提条件(环境或约束条件)、解法和效果。设计模式的定义与分类设计模式的定义设计模式(DesignPattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结,使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。设计模式的定义与分类设计模式的基本要素设计模式一般有如下几个基本要素:模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式,其中的关键元素包括以下四个方面:•模式名称(Patternname)•问题(Problem)•解决方案(Solution)•效果(Consequences)设计模式的定义与分类设计模式学习步骤本书将按照以下次序来学习设计模式:•模式动机与定义•模式结构与分析•模式实例与解析•模式效果与应用•模式扩展设计模式的定义与分类设计模式的分类根据其目的(模式是用来做什么的)可分为创建型(Creational),结构型(Structural)和行为型(Behavioral)三种:•创建型模式主要用于创建对象。•结构型模式主要用于处
本文标题:_常用软件设计模式
链接地址:https://www.777doc.com/doc-3951509 .html