1、软件设计模式与体系结构面向对象设计原则概述w 面向对象设计原则简介 常用的面向对象设计原则包括常用的面向对象设计原则包括7个，这些原则并不是孤立存在的，它们相个，这些原则并不是孤立存在的，它们相互依赖，相互补充。互依赖，相互补充。设计原则名称设计原则名称设计原则简介设计原则简介重要性重要性单一职责原则单一职责原则SRPSRP(Single Responsibility(Single Responsibility Principle)Principle)类的职责要单一，不能将太多的职责放在一个类的职责要单一，不能将太多的职责放在一个类中类中开闭原则开闭原则OCPOCP(Open-Closed(O
2、pen-Closed PrinciplePrinciple）软件实体对扩展是开放的，但对修改是关闭的，软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个实体的基础上去扩展其功能即在不修改一个实体的基础上去扩展其功能里氏代换原则里氏代换原则LSPLSP(LiskovLiskov Substitution Substitution rinciplerinciple)在软件系统中，一个可以接受基类对象的地方在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象必然可以接受一个子类对象依赖倒转原则依赖倒转原则DIPDIP(Dependency(Dependency Inversion
3、Principle)Inversion Principle)要针对抽象层编程，而不要针对具体类编程要针对抽象层编程，而不要针对具体类编程接口隔离原则接口隔离原则ISPISP(Interface Segregation(Interface Segregation Principle)Principle)使用多个专门的接口来取代一个统一的接口使用多个专门的接口来取代一个统一的接口 合成复用原则合成复用原则CRPCRP(Composite(Composite Reuse Principle)Reuse Principle)在系统中应该尽量多使用组合和聚合关联关系，在系统中应该尽量多使用组合和聚合关联
4、关系，尽量少使用甚至不使用继承关系尽量少使用甚至不使用继承关系迪米特法则迪米特法则LoDLoD(Law of Demeter)(Law of Demeter)一个软件实体对其他实体的引用越少越好，或一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互引入一个第三者发生间接交互单一职责原则 w 单一职责原则定义 单一职责原则单一职责原则(Single Responsibility Principle,SRP)定义如下：定义如
5、下：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。其英文定义为：其英文定义为：Every object should have a single responsibility,and that responsibility should be entirely encapsulated by the class.另一种定义方式如下：另一种定义方式如下：就一个类而言，应该就一个类而言，应该仅有一个引起它变化的原因仅有一个引起它变化的原因。其英文定义为：其英文定义为：There should never be more than one reason for a class to
6、 change.单一职责原则 w 单一职责原则分析 一个类（或者大到模块，小到方法）承担的职责越多，它被复用的一个类（或者大到模块，小到方法）承担的职责越多，它被复用的可能性越小可能性越小，而且如果一个类承担的职责过多，就相当于将这些职，而且如果一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作。作。类的职责主要包括两个方面：类的职责主要包括两个方面：数据职责和行为职责数据职责和行为职责，数据职责通过数据职责通过其属性来体现其属性来体现，而，而行为职责通过其方法来体现行为职责通过其方法来体
7、现。单一职责原则是实现单一职责原则是实现高内聚、低耦合高内聚、低耦合的指导方针，在很多代码重构的指导方针，在很多代码重构手法中都能找到它的存在，它是最简单但又最难运用的原则，需要手法中都能找到它的存在，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。设计人员具有较强的分析设计能力和相关重构经验。单一职责原则 w 单一职责原则实例 实例说明实例说明 某基于Java的C/S系统的“登录功能”通过如下登录类(Login)实现：现使用单一职责原则对其进行重
8、构。单一职责原则 w 单一职责原则实例 实例解析实例解析 开闭原则w 开闭原则定义 变化是绝对的，但应通过扩展，而不是修改现有代码来变化是绝对的，但应通过扩展，而不是修改现有代码来实现实现开闭原则开闭原则(Open-Closed Principle,OCP)定义如下：定义如下：一个软件实体应当对 扩展扩展 开放，对 修改修改 关闭。也就是说在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，即实现在不修改源代码的情况下改变这个模块的行为。其英文定义为：其英文定义为：Software entities should be open for extension,but closed
9、for modification.开闭原则w 开闭原则分析 开闭原则由开闭原则由Bertrand Meyer于于1988年提出，它是面向年提出，它是面向对象设计中最重要的原则之一。对象设计中最重要的原则之一。在开闭原则的定义中，在开闭原则的定义中，软件实体可以指一个软件模块、软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类一个由多个类组成的局部结构或一个独立的类。开闭原则w 开闭原则分析 抽象化抽象化是是 开闭原则开闭原则 的关键。的关键。开闭原则还可以通过一个更加具体的开闭原则还可以通过一个更加具体的“对可变性封对可变性封装原则装原则”来描述，对可变性封装原则来描述，对可
10、变性封装原则(Principle of Encapsulation of Variation,EVP)要求找到系统要求找到系统的可变因素并将其封装起来。的可变因素并将其封装起来。需求不断变化，使系统在不断变化中保持稳定，多扩展，少修改。多扩展，少修改。利用抽象，隔离变化。面向对象的核心将频繁变化的部分抽象抽象拒绝不成熟的抽象开闭原则w 开闭原则实例 实例说明实例说明 某图形界面系统提供了各种不同形状的按钮，客户端代码可针对这些按钮进行编程，用户可能会改变需求要求使用不同的按钮可能会改变需求要求使用不同的按钮，原始设计方案如图所示：现对该系统进行重构，使之满足开闭原则的要求。LoginForm-
11、button:CircleButton+display():voidCircleButton+view():voidLoginForm-button:RectangleButton+display():voidRectangleButton+view():void变化开闭原则w 开闭原则实例 实例解析实例解析 很多软件设计模式，就很多软件设计模式，就是为了更好的体现（实是为了更好的体现（实现）开闭原则。现）开闭原则。依赖倒转原则 w 依赖倒转原则定义 依赖倒转原则依赖倒转原则(Dependence Inversion Principle,DIP)的定义的定义如下：如下：高层模块不应该依赖低层模
12、块低层模块，它们都应该依赖抽象抽象。抽象不应该依赖于细节细节，细节应该依赖于抽象依赖于抽象。其英文定义为：其英文定义为：High level modules should not depend upon low level modules,both should depend upon abstractions.Abstractions should not depend upon details,details should depend upon abstractions.另一种表述为：另一种表述为：要针对接口编程针对接口编程，不要针对实现编程针对实现编程。其英文定义为：其英文定义为：Pr
13、ogram to an interface,not an implementation.依赖倒转原则 w 依赖倒转原则分析简单来说，依赖倒转原则就是指：简单来说，依赖倒转原则就是指：代码要依赖于抽象的代码要依赖于抽象的类，而不要依赖于具体的类类，而不要依赖于具体的类；要针对接口或抽象类编程，要针对接口或抽象类编程，而不是针对具体类编程而不是针对具体类编程。实现开闭原则的关键是抽象化实现开闭原则的关键是抽象化，并且，并且从抽象化导出具体从抽象化导出具体化实现化实现，如果说，如果说开闭原则是面向对象设计的开闭原则是面向对象设计的目标目标的话的话，那么那么依赖倒转原则就是面向对象设计的主要依赖倒转原
14、则就是面向对象设计的主要手段手段。所有依赖关系，均应终止于抽象类或者接口依赖倒转原则 w 依赖倒转原则分析（如何实现依赖倒转？）类之间的耦合类之间的耦合 零耦合关系 具体耦合关系 抽象耦合关系 依赖倒转原则要求客户端依赖于抽象耦合，依赖倒转原则要求客户端依赖于抽象耦合，以抽象方以抽象方式耦合是依赖倒转原则的关键式耦合是依赖倒转原则的关键。里氏代换原则里氏代换原则里氏代换原则 w 里氏代换原则定义 更容易理解的定义方式：更容易理解的定义方式：所有引用引用 基类（父类）的地方必须能透明地使用其子类的对象。或者：把所有的父类，全部替换为子类，则软件行为没有变化其英文定义为：其英文定义为：Functi
15、ons that use pointers or references to base classes must be able to use objects of derived classes without knowing it.只有子类可替换掉父类，父类才可真正被复用依赖倒置原则的根本里氏代换原则 w 里氏代换原则分析里氏代换原则是里氏代换原则是实现开闭原则的重要方式之一实现开闭原则的重要方式之一。由于使用基类对象的地方都可以使用子类对象，因此由于使用基类对象的地方都可以使用子类对象，因此在在程序中尽量使用程序中尽量使用基类类型基类类型 来对对象进行定义。来对对象进行定义。而而在运行时
16、再确定其子类类型在运行时再确定其子类类型，用，用子类对象子类对象 来替换来替换父类父类对象对象。子类可替换性，使得使用父类的模块，不修改实现扩展。（引用不同的子类对象）依赖倒转原则 w 依赖倒转原则分析依赖注入依赖注入 构造注入(Constructor Injection)：通过构造函数注入实例变量。设值注入(Setter Injection)：通过Setter方法注入实例变量。接口注入(Interface Injection)：通过接口方法注入实例变量。依赖倒转原则w 依赖倒转原则实例实例说明实例说明 某系统提供一个数据转换模块，可以将来自不同数据源的数据转换成多种格式，如可以转换来自数据库
17、的数据(DatabaseSource)、也可以转换来自文本文件的数据(TextSource)，转换后的格式可以是XML文件(XMLTransformer)、也可以是XLS文件(XLSTransformer)等。依赖倒转原则w 依赖倒转原则实例实例说明实例说明 由于需求的变化，该系统可能需要增加新的数据源或者新的文件格式，每增加一个新的类型的数据源或者新的类型的文件格式，客户类MainClass都需要修改源代码，以便使用新的类，但违背了开闭原则。现使用依赖倒转原则对其进行重构。依赖倒转原则w 依赖倒转原则实例实例解析实例解析 设计模式的诞生与发展w 模式的诞生与定义 模式起源于建筑业而非软件业模
18、式起源于建筑业而非软件业 模式模式(Pattern)之父之父美国加利佛尼亚大学环境结构中心研究所美国加利佛尼亚大学环境结构中心研究所所长所长Christopher Alexander博士博士 A Pattern Language:Towns,Buildings,Construction253个建筑和城市规划模式个建筑和城市规划模式 模式模式 Context（模式可适用的前提条件）Theme或Problem（在特定条件下要解决的目标问题）Solution（对目标问题求解过程中各种物理关系的记述）设计模式的诞生与发展w 模式的诞生与定义 Alexander给出了关于模式的经典定义：每个模式都描给出
19、了关于模式的经典定义：每个模式都描述了一个述了一个在我们的环境中不断出现的问题在我们的环境中不断出现的问题，然后描述了，然后描述了该问题的该问题的解决方案解决方案的核心，通过这种方式，我们可以无的核心，通过这种方式，我们可以无数次地重用那些已有的解决方案，无需再重复相同的工数次地重用那些已有的解决方案，无需再重复相同的工作。作。A pattern is a solution to a problem in a context 模式是在模式是在特定环境特定环境中中解决问题解决问题的一种的一种方案方案 设计模式的诞生与发展w 软件模式 1990年，软件工程界开始关注年，软件工程界开始关注Chris
20、topher Alexander等等在这一住宅、公共建筑与城市规划领域的重大突破，最早将在这一住宅、公共建筑与城市规划领域的重大突破，最早将该模式的思想引入软件工程方法学的是该模式的思想引入软件工程方法学的是1991-1992年以年以“四四人组人组(Gang of Four，GoF，分别是，分别是Erich Gamma,Richard Helm,Ralph Johnson和和John Vlissides)”自称自称的四位著名软件工程学者，他们在的四位著名软件工程学者，他们在1994年归纳发表了年归纳发表了23种种在软件开发中使用频率较高的设计模式，旨在在软件开发中使用频率较高的设计模式，旨在用
21、模式来统一用模式来统一沟通面向对象方法在分析、设计和实现间的鸿沟沟通面向对象方法在分析、设计和实现间的鸿沟。设计模式的诞生与发展w 软件模式 软件模式是将模式的一般概念应用于软件开发领域，即软件模式是将模式的一般概念应用于软件开发领域，即软件开发的软件开发的总体指导思路或参照样板总体指导思路或参照样板。软件模式并非仅限于设计模式，还包括。软件模式并非仅限于设计模式，还包括架构模式、分析模式和过程模式等，实际上，架构模式、分析模式和过程模式等，实际上，在软件生存期的每一在软件生存期的每一个阶段都存在着一些被认同的模式个阶段都存在着一些被认同的模式。软件模式可以认为是软件模式可以认为是对软件开发这
22、一特定对软件开发这一特定“问题问题”的的“解法解法”的某的某种统一表示种统一表示，它和，它和Alexander所描述的模式定义完全相同，即所描述的模式定义完全相同，即软件软件模式等于一定条件下的出现的问题以及解法模式等于一定条件下的出现的问题以及解法。软件模式的基础结构。软件模式的基础结构由由4个部分构成：个部分构成：问题描述问题描述、前提条件（环境或约束条件）、解法前提条件（环境或约束条件）、解法和和效果效果。设计模式的定义与分类 w 设计模式的定义 设计模式设计模式(Design Pattern)是一套是一套被反复使用、多数人被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结知晓
23、的、经过分类编目的、代码设计经验的总结，使用，使用设计模式是为了可重用代码、让代码更容易被他人理解、设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。保证代码可靠性。设计模式的定义与分类w 设计模式的基本要素 设计模式一般有如下几个基本要素：模式名称、问题、设计模式一般有如下几个基本要素：模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式，其目的、解决方案、效果、实例代码和相关设计模式，其中的关键元素包括以下四个方面：中的关键元素包括以下四个方面：模式名称(Pattern name)问题(Problem)解决方案(Solution)效果(Consequences)设计
24、模式的定义与分类w设计模式学习步骤 按照以下次序来学习设计模式：按照以下次序来学习设计模式：模式动机与定义 模式结构与分析 模式实例与解析 模式效果与应用 模式扩展 设计模式的定义与分类w设计模式的分类根据其根据其目的目的（模式是用来做什么的）可分为（模式是用来做什么的）可分为创建型创建型(Creational)，结构型结构型(Structural)和和行为型行为型(Behavioral)三种：三种：创建型模式主要用于创建对象。结构型模式主要用于处理类或对象的组合。行为型模式主要用于描述对类或对象怎样交互和怎样分配职责。GoF设计模式简介 范围范围目的目的创建型模式创建型模式结构型模式结构型模
25、式行为型模式行为型模式类模式类模式 工厂方法模式（类）适配器模式解释器模式模板方法模式对象模对象模式式抽象工厂模式建造者模式原型模式单例模式（对象）适配器模式桥接模式组合模式装饰模式外观模式享元模式代理模式职责链模式命令模式迭代器模式中介者模式备忘录模式观察者模式状态模式策略模式访问者模式创建型模式w 创建型模式概述创建型模式创建型模式(Creational Pattern)对类的实例化过程进对类的实例化过程进行了抽象，能够行了抽象，能够将软件模块中对象的创建和对象的使用将软件模块中对象的创建和对象的使用分离分离。为了使软件的结构更加清晰，外界对于这些对象。为了使软件的结构更加清晰，外界对于这
26、些对象只需要知道它们共同的接口，而不清楚其具体的实现细只需要知道它们共同的接口，而不清楚其具体的实现细节，使整个系统的设计更加符合单一职责原则。节，使整个系统的设计更加符合单一职责原则。创建型模式w 创建型模式概述创建型模式在创建型模式在创建什么创建什么(What)，由谁创建由谁创建(Who)，何何时创建时创建(When)等方面都为软件设计者提供了尽可能大等方面都为软件设计者提供了尽可能大的灵活性。创建型模式的灵活性。创建型模式隐藏了类的实例的创建细节，通隐藏了类的实例的创建细节，通过隐藏对象如何被创建和组合在一起达到使整个系统独过隐藏对象如何被创建和组合在一起达到使整个系统独立的目的立的目的
27、。创建型模式简单工厂模式（简单工厂模式（Simple Factory）工厂方法模式（工厂方法模式（Factory Method）抽象工厂模式（抽象工厂模式（Abstract Factory）建造者模式（建造者模式（Builder）原型模式（原型模式（Prototype）单例模式（单例模式（Singleton）w 创建型模式简介简单工厂模式w 模式动机只需要知道水果的名字则可得到相应的水果只需要知道水果的名字则可得到相应的水果简单工厂模式w 模式动机 考虑一个简单的软件应用场景，一个软件系统可以提供多个考虑一个简单的软件应用场景，一个软件系统可以提供多个外观不同的按钮（如圆形按钮、矩形按钮、菱形
28、按钮等），外观不同的按钮（如圆形按钮、矩形按钮、菱形按钮等），这些按钮都源自同一个基类这些按钮都源自同一个基类，不过在继承基类后不同的子类，不过在继承基类后不同的子类修改了部分属性从而使得它们可以呈现不同的外观修改了部分属性从而使得它们可以呈现不同的外观 我们希望在使用这些按钮时，我们希望在使用这些按钮时，不需要知道这些具体按钮类的不需要知道这些具体按钮类的名字，只需要知道表示该按钮类的一个参数，并提供一个名字，只需要知道表示该按钮类的一个参数，并提供一个调调用方便用方便 的方法，把该参数传入方法即可的方法，把该参数传入方法即可返回返回一个相应的按钮一个相应的按钮对象对象，此时，就可以使用简单
29、工厂模式。，此时，就可以使用简单工厂模式。简单工厂模式w 模式定义简单工厂模式简单工厂模式(Simple Factory Pattern)：又称为：又称为静静态工厂方法态工厂方法(Static Factory Method)模式模式，它属于，它属于类创建型模式。类创建型模式。在简单工厂模式中，可以在简单工厂模式中，可以根据参数的不同返回不同类根据参数的不同返回不同类的实例的实例。简单工厂模式。简单工厂模式专门定义一个类来负责创建其专门定义一个类来负责创建其他类的实例他类的实例，被创建的实例通常都具有被创建的实例通常都具有共同的父类共同的父类。可用父类引用指向对象简单工厂模式w 模式结构接口或抽
30、象父类简单工厂模式w 模式分析 分析如下代码：分析如下代码：public void pay(String type)if(type.equalsIgnoreCase(cash)/创建先进支付的对象创建先进支付的对象 /现金支付处理代码现金支付处理代码 else if(type.equalsIgnoreCase(creditcard)/信用卡支付处理代码（生成对象）信用卡支付处理代码（生成对象）else if(type.equalsIgnoreCase(voucher)/代金券支付处理代码（生成对象）代金券支付处理代码（生成对象）else 代码复杂，难以维护代码复杂，难以维护简单工厂模式w 模式
31、分析 重构后的代码：重构后的代码：public abstract class AbstractPay public abstract void pay();public class CashPay extends AbstractPay public void pay()/现金支付处理代码 抽象支付类抽象支付类具体支付类具体支付类简单工厂模式w 模式分析 重构后的代码：重构后的代码：public class PayMethodFactory public static AbstractPay getPayMethod(String type)if(type.equalsIgnoreCase(c
32、ash)return new CashPay();/根据参数创建具体产品 else if(type.equalsIgnoreCase(creditcard)return new CreditcardPay();/根据参数创建具体产品 支付工厂支付工厂简单工厂模式w 模式优缺点 简单工厂模式的优点简单工厂模式的优点工厂工厂类含有必要的判断逻辑，可以决定决定在什么时候创建哪一个产品类的实例，客户端客户端可以免除直接创建产品对象的责任，而仅仅“消费消费”产品；简单工厂模式通过这种做法实现了对责任的分割。客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，
33、通过简单工厂模式可以减少使用者的记忆量。通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。单例模式单例模式w模式动机 对于系统中的某些类来说，只有一个实例很重要对于系统中的某些类来说，只有一个实例很重要，例如，一个系统，例如，一个系统中可以存在多个打印任务，但是只能有一个正在工作的任务；一个中可以存在多个打印任务，但是只能有一个正在工作的任务；一个系统只能有一个窗口管理器或文件系统；一个系统只能有一个计时系统只能有一个窗口管理器或文件系统；一个系统只能有一个计时工具或工具或ID（序号）生成器。（序号）生成器。单例模式w模式动机如何保证
34、一个类只有一个实例并且这个实例易于被访问如何保证一个类只有一个实例并且这个实例易于被访问呢？呢？定义一个全局变量可以确保对象随时都可以被访问，定义一个全局变量可以确保对象随时都可以被访问，但不能防止我们实例化多个对象但不能防止我们实例化多个对象。一个更好的解决办法是一个更好的解决办法是让类自身负责保存它的唯一实例让类自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建，并且它可以提供这个类可以保证没有其他实例被创建，并且它可以提供一个访问该实例的方法。这就是单例模式的模式动机。一个访问该实例的方法。这就是单例模式的模式动机。单例模式w 模式定义单例模式单例模式(Singleton Pat
35、tern)：单例模式：单例模式确保某一个确保某一个类只有一个实例，而且自行实例化并向整个系统提供这类只有一个实例，而且自行实例化并向整个系统提供这个实例个实例，这个类称为单例类，它提供全局访问的方法。，这个类称为单例类，它提供全局访问的方法。单例模式的要点有三个：一是单例模式的要点有三个：一是某个类只能有一个实例某个类只能有一个实例；二是二是它必须自行创建这个实例它必须自行创建这个实例；三是；三是它必须自行向整个它必须自行向整个系统提供这个实例系统提供这个实例。单例模式是一种对象创建型模式。单例模式是一种对象创建型模式。单例模式又名单件模式或单态模式。单例模式又名单件模式或单态模式。单例模式w
36、 模式结构instanceif(instance=null)instance=new Singleton();return instance;Singleton-instance:Singleton-+Singleton()getInstance().:Singleton单例模式w 模式分析单例模式的目的是保证一个类仅有一个实例，并提供一单例模式的目的是保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例模式包含的角色只有一个，个访问它的全局访问点。单例模式包含的角色只有一个，就是单例类就是单例类Singleton。单例类拥有一个私有构造单例类拥有一个私有构造函数，确保用户无法通过函数，
37、确保用户无法通过new关键字直接实例化它关键字直接实例化它。除。除此之外，该模式中包含一个静态私有成员变量与静态公此之外，该模式中包含一个静态私有成员变量与静态公有的工厂方法，该有的工厂方法，该工厂方法负责检验实例的存在性并实工厂方法负责检验实例的存在性并实例化自己，然后存储在静态成员变量中，以确保只有一例化自己，然后存储在静态成员变量中，以确保只有一个实例被创建个实例被创建。单例模式w 模式分析 单例模式的实现代码如下所示：单例模式的实现代码如下所示：public class Singletonprivate static Singleton instance=null;/静态私有成员变量/
38、私有构造函数private Singleton()/静态公有工厂方法，返回唯一实例public static Singleton getInstance()if(instance=null)instance=new Singleton();return instance;单例模式w 模式分析在单例模式的实现过程中，需要注意如下三点：在单例模式的实现过程中，需要注意如下三点：单例类的构造函数为私有；提供一个自身的静态私有成员变量；提供一个公有的静态工厂方法。单例模式w 单例模式实例与解析实例一：身份证号码实例一：身份证号码 在现实生活中，居民身份证号码具有唯一性，同一个人不允许有多个身份证号码，
39、第一次申请身份证时将给居民分配一个身份证号码，如果之后因为遗失等原因补办时，还是使用原来的身份证号码，不会产生新的号码。现使用单例模式模拟该场景。单例模式w 模式优缺点单例模式的优点单例模式的优点 提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它，并为设计及开发团队提供了共享的概念。由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。允许可变数目的实例。我们可以基于单例模式进行扩展，使用与单例控制相似的方法来获得指定个数的对象实例。单例模式w 模式适用环境在以下情况下可以使用单
40、例模式：在以下情况下可以使用单例模式：系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器，或者需要考虑资源消耗太大而只允许创建一个对象。客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途径访问该实例。在一个系统中要求一个类只有一个实例时才应当使用单例模式。反过来，如果一个类可以有几个实例共存，就需要对单例模式进行改进，使之成为多例模式。结构型模式w 结构型模式简介 适配器模式适配器模式(Adapter)桥接模式桥接模式(Bridge)组合模式组合模式(Composite)装饰模式装饰模式(Decorator)外观模式外观模式(Facade)享元模式享元模式
41、(Flyweight)代理模式代理模式(Proxy)结构型模式w 结构型模式概述 结构型模式结构型模式(Structural Pattern)描述描述如何将类或者对如何将类或者对象结合在一起形成更大的结构象结合在一起形成更大的结构，就像搭积木，可以通过，就像搭积木，可以通过简单积木的组合形成复杂的、功能更为强大的结构。简单积木的组合形成复杂的、功能更为强大的结构。结构型模式w 结构型模式概述结构型模式可以分为结构型模式可以分为类结构型模式类结构型模式和和对象结构型模式对象结构型模式：类结构型模式关心类的组合，由多个类可以组合成一个更大的系统，在类结构型模式中一般只存在继承关系和实现关系。对象结
42、构型模式关心类与对象的组合，通过关联关系使得在一个类中定义另一个类的实例对象，然后通过该对象调用其方法。适配器模式适配器模式w模式动机适配器模式w 模式动机 在软件开发中采用类似于电源适配器的设计和编码技巧被称为在软件开发中采用类似于电源适配器的设计和编码技巧被称为适配适配器模式器模式。通常情况下，通常情况下，客户端可以通过目标类的接口访问它所提供的服务客户端可以通过目标类的接口访问它所提供的服务。有时，现有的类可以满足客户类的功能需要，但是它所提供的接口有时，现有的类可以满足客户类的功能需要，但是它所提供的接口不一定是客户类所期望的不一定是客户类所期望的，这可能是因为现有类中方法名与目标，这
43、可能是因为现有类中方法名与目标类中定义的方法名不一致等原因所导致的。类中定义的方法名不一致等原因所导致的。在这种情况下，在这种情况下，现有的接口需要转化为客户类期望的接口现有的接口需要转化为客户类期望的接口，这样保，这样保证了对现有类的重用。如果不进行这样的转化，客户类就不能利用证了对现有类的重用。如果不进行这样的转化，客户类就不能利用现有类所提供的功能，适配器模式可以完成这样的转化。现有类所提供的功能，适配器模式可以完成这样的转化。适配器模式w 模式动机 在适配器模式中可以定义一个包装类，包装不兼容接口的对象，这在适配器模式中可以定义一个包装类，包装不兼容接口的对象，这个包装类指的就是个包装
44、类指的就是适配器适配器(Adapter)，它所包装的对象就是，它所包装的对象就是适配者适配者(Adaptee)，即被适配的类。，即被适配的类。适配器提供客户类需要的接口，适配器提供客户类需要的接口，适配器的实现就是把客户类的请求适配器的实现就是把客户类的请求转化为对适配者的相应接口的调用转化为对适配者的相应接口的调用。也就是说：也就是说：当客户类调用适配器的方法时，在适配器类的内部将调当客户类调用适配器的方法时，在适配器类的内部将调用适配者类的方法，而这个过程对客户类是透明的，客户类并不直用适配者类的方法，而这个过程对客户类是透明的，客户类并不直接访问适配者类。接访问适配者类。因此，因此，适配
45、器可以使由于接口不兼容而不能交互适配器可以使由于接口不兼容而不能交互的类可以一起工作的类可以一起工作。这就是适配器模式的模式动机。这就是适配器模式的模式动机。适配器模式w 模式定义适配器模式适配器模式(Adapter Pattern)：将一个接口转换成客将一个接口转换成客户希望的另一个接口户希望的另一个接口，适配器模式，适配器模式使接口不兼容的那些使接口不兼容的那些类可以一起工作类可以一起工作，其别名为，其别名为包装器包装器(Wrapper)。适配器。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式既可以作为类结构型模式，也可以作为对象结构型模式。模式。适配器模式w 模式结构适配器模
46、式包含如下角色：适配器模式包含如下角色：Target：目标抽象类 Adapter：适配器类 Adaptee：适配者类 Client：客户类适配器模式w 模式结构类适配器类适配器Adapter+request().Target+request().Adaptee+specificRequest().ClientspecificRequest();接口实际工作的类继承自实际工作的类同时实现（符合）接口适配器模式w 模式结构对象适配器对象适配器实例化了Adaptee对象符合要求的接口类适配器模式w 模式分析典型的典型的类适配器类适配器代码：代码：public class Adapter extend
47、s Adaptee implements Targetpublic void request()specificRequest();适配器模式w 模式分析典型的对象适配器代码：典型的对象适配器代码：public class Adapter extends Targetprivate Adaptee adaptee;public Adapter(Adaptee adaptee)this.adaptee=adaptee;public void request()adaptee.specificRequest();适配器模式w 适配器模式实例与解析实例一：仿生机器人实例一：仿生机器人 现需要设计一个
48、可以模拟各种动物行为的机器人，在机器人中定义了一系列方法，如机器人叫喊方法cry()、机器人移动方法move()等。如果希望在不修改已有代码的基础上使得机器人能够像狗一样叫，像狗一样跑，使用适配器模式进行系统设计。适配器模式w 适配器模式实例与解析实例一：仿生机器人实例一：仿生机器人 适配器模式w 适配器模式实例与解析实例二：加密适配器实例二：加密适配器 某系统需要提供一个加密模块，将用户信息（如密码等机密信息）加密之后再存储在数据库中，系统已经定义好了数据库操作类。为了提高开发效率，现需要重用已有的加密算法，这些算法封装在一些由第三方提供的类中，有些甚至没有源代码。使用适配器模式设计该加密模
49、块，实现在不修改现有类的基础上重用第三方加密方法。练习w 1 两相插座转化成三相插座使用适配器模式w 模式适用环境在以下情况下可以使用适配器模式：在以下情况下可以使用适配器模式：系统需要使用现有的类，而这些类的接口不符合系统的需要。想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。适配器模式w 模式优缺点适配器模式的优点适配器模式的优点 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，而无须修改原有代码。增加了类的透明性和复用性，将具体的实现封装在适配者类中，对于客户端类来说是透明的，而且提高了适配者的复用性。灵活性和扩
50、展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。适配器模式w 模式优缺点类适配器模式还具有如下优点：类适配器模式还具有如下优点：由于适配器类是适配者类的子类，因此可以在适配器类中置换一些适配者的方法，使得适配器的灵活性更强。类适配器模式的缺点如下：类适配器模式的缺点如下：对于Java、C#等不支持多重继承的语言，一次最多只能适配一个适配者类，而且目标抽象类只能为抽象类，不能为具体类，其使用有一定的局限性，不能将一个适配者类和它的子类都适配到目标接口。桥接模式桥接模式w模式动机设想如果要绘制矩形、圆形、椭圆、正方形，我
