设计模式期末考试复习

1、一What is design pattern ？模式 是在物体或事件上，产生的一种规律变化与自我重复的样式与过程。在模式之中,某些固定的元素不断以可预测的方式周期性重现。What is design pattern ？广义讲，软件设计模式是可解决一类软件问题并能重复使用的软件设计方案;狭义讲，设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述.是在类和对象的层次描述的可重复使用的软件设计问题的解决方案；面向对象设计模式体现的是程序整体的构思，所以有时候它也会出现在分析或者是概要设计阶段 设计模式的核心思想是通过增加抽象层，把变化部分从那些不变部分里分离出来GOF（Gan

2、g of Four）的设计模式定义:设计模式是在一个 上下文 中，对一个问题 的 解决方案，及其能够达到的效果.即模式的四要素:名称、上下文与问题、解决方案、效果.分类：23种设计模式：创建型:5种结构型：7种行为型：11种四要素：模式名称(Pattern Name)问题(Problem）：描述应该在何时使用模式.解释了设计问题和问题存在的前因后果,可能还描述模式必须满足的先决条件；解决方案（Solution)：描述了设计的组成成分、相互关系及各自的职责和协作方式。模式就像一个模板，可应用于多种场合，所以解决方案并不描述一个具体的设计或实现，而是提供设计问题的抽象描述和解决问题所采用的元素组合

3、（类和对象）；效果（consequences )：描述模式的应用效果及使用模式应权衡的问题都有哪些设计模式？GOF共提出23种设计模式：创建型：5种结构型：7种行为型：11种Creational Patterns用来创建对象的模式，抽象了实例化过程 Factory Method 工厂模式 父类负责定义创建对象的公共接口,而子类则负责生成具体对象，将类的实例化操作延迟到子类中完成；Abstract Factory 抽象工厂模式 为一个产品族提供统一的创建接口。当需要这个产品族的某一系列的时候，可以从抽象工厂中选出相应的系列创建一个具体的工厂类；Singleton 单例模式 保证一个类有且仅有一个

4、实例,提供一个全局访问点；Builder 建造者模式 将复杂对象创建与表示分离，同样的创建过程可创建不同的表示.允许用户通过指定复杂对象类型和内容来创建对象,用户不需要知道对象内部的具体构建细节;Prototype 原型模式 通过“复制”一个已经存在的实例来返回新的实例（不新建实例）。被复制的实例就是“原型”,这个原型是可定制的.原型模式多用于创建复杂的或者耗时的实例，因为这种情况下,复制一个已经存在的实例使程序运行更高效;或者创建值相等，只是命名不一样的同类数据；Structural Patterns结构型模式讨论的是类和对象的结构，它采用继承机制来组合接口或实现（类结构型模式），或者通过组

5、合一些对象来实现新的功能(对象结构型模式）Adapter 适配器模式将一个类的接口适配成用户所期待的接口.一个适配器允许因为接口不兼容而不能在一起工作的类工作在一起，做法是将类自己的接口包装在一个已存在的类中;Bridge 桥接模式桥接模式的用意是将问题的抽象和实现分离开来实现，通过用聚合代替继承来解决子类爆炸性增长的问题；Composite 组合模式 定义一个接口，使之用于单一对象,也可以应用于多个单一对象组成的对象组；Decorator 装饰模式 给对象动态添加额外的职责，就好像给一个物体加上装饰物，完善其功能；Faade 外观模式 外观模式为子系统提供了一个更高层次、更简单的接口,从而降

6、低了子系统的复杂度，使子系统更易于使用和管理。外观承担了子系统中类交互的责任Flyweight 享元模式 Flyweight是一个共享对象，它可以同时在不同上下文(Context)使用;Proxy 代理模式 在软件系统中，有些对象有时候由于跨越网络或者其他障碍,而不能够或者不想直接访问另一个对象,直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切,这就是代理(Proxy）模式;Behavioral Patterns着力解决的是类实体之间的通讯关系，希望以面向对象的方式描述一个控制流程。Chain of Responsibili

7、ty 责任链模式 很多对象由每一个对象对其下一个对象的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使系统可以在不影响客户端的情况下动态的重新组织链和分配责任；Command 命令模式 将请求及其参数封装成一个对象，作为命令发起者和接收者的中介，可以对这些请求排队或记录请求日志，以及支持可撤销操作;Interpreter 解释器模式 给定一个语言,定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子；Iterator 迭代器模式 提供一种方法顺序访问一个聚合对象中各个

8、元素， 而又不需暴露该对象的内部表示；Mediator 中介者模式 用一个中介对象来封装一系列的对象交互;Memento 备忘录模式 在不破坏封装性的前提下,捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态；Observer 观察者模式 定义了对象之间一对多的依赖,当这个对象的状态发生改变的时候,多个对象会接受到通知，有机会做出反馈；State 状态模式 允许一个“对象”在其内部状态改变的时候改变其行为，即不同的状态，不同的行为Strategy 策略模式 定义一组算法，将每个算法都封装起来，并且使它们之间可以互换.策略模式使这些算法在客户端调用它们的

9、时候能够互不影响地变化；Template 模板模式 定义了一个算法步骤，并允许子类为一个或多个步骤提供实现。子类在不改变算法架构的情况下，可重新定义算法中某些步骤;Visitor 访问者模式 表示一个作用于某对象结构中的各元素的操作.可以在不改变各元素的类的前提下定义作用于这些元素的新操作；面向对象方法抽象（Abstraction）封装（Encapsulation）多态（Polymorphism）继承(Inheritance）Object-Oriented Method类的功能要单一，体现了抽象加强内聚，松散耦合好的封装性类的粒度要合理实现类不能依赖使用类应考虑灵活性,也就是可配置，可维护要考

10、虑性能，可伸缩性要考虑后续的变化,也就是可扩展性要考虑合理的复用，这是平衡的艺术要合理的考虑接口和抽象类的使用尽量减少类间的交互次数和交互的信息量访问对象必须通过接口，不能绕过接口直接访问OO design principles开闭原则 （OCP)单一职责原则（SRP)里氏替换原则(LSP)依赖倒置原则（DIP)接口隔离原则（ISP)迪米特原则（LoD）单一职责原则（Single Responsibility Principle, SRP）定义：就一个类而言，应该仅有一个引起它变化的原因；每一个引起类变化的原因就是一个职责，当类具有多职责时，应把多余职责分离出去,分别创建一些类来完成每一个职责

11、；每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化；里氏替换原则（Liskov Substitution Principle， LSP）定义：所有引用基类的地方必须能透明地使用其子类的对象里氏替换原则是继承复用的基石，只有当派生类可以替换掉其基类，而软件功能不受影响时，基类才能真正被复用，派生类也才能够在基类的基础上增加新的行为LSP本质：在同一个继承体系中的对象应该有共同的行为特征里氏替换原则包含了两层重要含义:子类必须完全的实现父类的方法；子类可以有自己的个性依赖倒置原则（Dependence Inversion Principle， DIP）定义：高层模块不应依赖低层模块

12、，二者都应该依赖于抽象高层模块只应该包含重要的业务模型和策略选择，低层模块则是不同业务和策略的实现；高层抽象不依赖高层和低层模块的具体实现,最多只依赖于低层的抽象;低层抽象和实现也只依赖于高层抽象 ；辅助原则 任何变量都不应该持有一个指向具体类的引用;任何类都不应该从具体类派生；任何方法都不应覆盖其任何基类中已经实现了的方法 ;DIP引例 驾驶汽车依赖倒置原则（DIP）另一种理解：客户类和服务类都应该依赖于抽象（接口），并且客户类拥有接口。依赖是有方向的，客户类依赖于服务类。DIP引例 驾驶汽车DIP引例 驾驶汽车接口隔离原则（Interface Separate Principle, ISP

13、）定义：类间的依赖关系应该建立在最小的接口上。多个和客户相关的接口要好于一个通用接口；如果一个类有几个使用者，与其让这个类载入所有使用者需要使用的所有方法，还不如为每个使用者创建一个特定接口,并让该类分别实现这些接口；ISP引例 - 星探查询ISP引例 - 星探查询接口隔离原则（ISP）迪米特原则（Law of Demeter，LoD)LoD引例 人数清点LoD引例 - 人数清点LoD引例 人数清点开闭原则（Open-Closed Principle , OCP）定义：软件对扩展是开放的，对修改是关闭的。开发一个软件时,应可以对其进行功能扩展(开放),在进行扩展的时候，不需要对原来的程序进行修

14、改（关闭）好处：在软件可用性上非常灵活。可以在软件完成后对软件进行扩展，加入新的功能。这样，软件就可通过不断的增加新模块满足不断变化的新需求由于不修改软件原来的模块，不用担心软件的稳定性实现的主要原则抽象原则：把系统的所有可能的行为抽象成一个底层；由于可从抽象层导出一个或多个具体类来改变系统行为，因此对于可变部分，系统设计对扩展是开放的；可变性封装原则：对系统所有可能发生变化的部分进行评估和分类，每一个可变的因素都单独进行封装;COP引例 - 书店销售书籍COP引例 书店销售书籍项目投产了，书籍正常销售出去，书店也盈利了。从2008年开始，全球经济都开始下滑，对零售业影响还是比较大，书店为了生

15、存开始打折销售：所有40元以上的书籍9折销售,其他的8折销售。对已经投产的项目来说，这就是一个变化，我们来看看这样的一个需求变化，我们该怎么去应对，有三种方法可以解决这个问题：修改接口：在IBook上新增加一个方法getOffPrice()；修改实现类：修改NovelBook类中的方法，直接在getPrice（)中实现打折处理；通过扩展实现变化。增加一个子类OffNovelBook，覆写getPrice方法；COP引例 书店销售书籍二 The Strategy Pattern策略模式： 定义了算法族，分别封装起来，让他们之间可以互相替换，此模式让算法的变化独立于使用算法的客户.传统策略算法实现

16、的缺点：使用算法的类复杂而难于维护；不同的时候需要不同的算法;算法的实现和使用算法的对象紧紧耦合在一起；将每种算法的实现都剥离出来构成一个个独立算法对象，再从这些对象中抽象出公共算法接口，最后将算法接口组合到使用算法类中。策略模式的意图和适用性意图：定义一系列算法，一个个进行封装，并使其可相互替换.策略模式使得算法可独立于使用它的客户而变化适用场合在软件构建过程中，某些对象使用的算法可能多种多样,经常改变，如果将这些算法都编码到对象中，将会使得对象变得异常复杂;而且有时候支持不同的算法也是一个性能负担；如何在运行时根据需要透明地更改对象的算法？如何将算法与对象本身解耦，从而避免上述问题？策略模

17、式很好地解决了这两个问题；策略模式的结构策略模式的参与者Strategy定义所有支持算法的公共接口Context使用该接口调用某ConcreteStrategy定义的算法ConcreteStrategy以Strategy接口实现某具体算法Context用一个ConcreteStrategy对象来配置维护一个对Strategy对象的引用可定义一个接口来让Strategy访问它的数据策略模式的效果分析算法和使用算法的对象相互分离，客户程序可以在运行时动态选择算法,代码复用性好，便于修改和维护；用组合替代继承,效果更好。若从Context直接生成子类，也可以实现对象的多种算法，但继承使子类和父类紧密

18、耦合,使Context类难以理解、难以维护和难以扩展。策略模式采用组合方式，使Context和Strategy之间的依赖很小，更利于代码复用；消除了冗长的条件语句序列，将不同的算法硬编码进一个类中，选择不同的算法必然要使用冗长的条件语句序列,采用策略模式将算法封装在一个个独立的Strategy类中消除了这些条件语句;策略模式的效果分析算法的动态选择，Strategy模式可以提供相同行为的不同实现,客户可以根据不同的上下文从不同的策略中选择算法;客户必须了解不同的Strategy,一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有什么不同；Strategy和Contex

19、t之间的通信开销加大，根据算法的需要，Context必须向每个不同的具体Strategy类实例传递不同的参数，因此Strategy接口就要传递所有这些不同参数的集合，导致Context会创建和传递一些永远用不到的参数；增加了类和对象数目，因为各种算法被抽取出来单独成类,导致了对象数目增加，这种情况在算法较多时更加严重；使用的设计原则“开-闭”原则(OCP） 单一职责原则(SRP） 里氏替换原则(LSP) 接口隔离原则（ISP）PracticePractice三Observer PatternDesigning the Weather StationImplementing the Weathe

20、r Station建立接口；在WeatherData中实现主题接口；建立布告板；构造环境,启动气象站； push and pull Pull VS Push推方式：当状态发生变化时，一次性将所有数据推给观察者;不向观察者开放内部数据接口；只要是观察者被注册，观察者将始终收到数据；拉方式：观察者可根据需要取Subject提供的数据;Subject必须提供数据接口（getter)；观察者可按自己的要求决定是否接收数据；BULLET POINTSThe Observer Pattern defines a one-to-many relationship between objects。Subjec

21、ts, or as we also know them, Observables, update Observers using a common interface.Observers are loosely coupled in that the Observable knows nothing about them， other than that they implement the Observer Interface。You can push or pull data from the Observable when using the pattern （pull is consi

22、dered more “correct”）。BULLET POINTSDont depend on a specific order of notification for your Observers.Java has several implementations of the Observer Pattern， including the general purpose java。util.Observable。Watch out for issues with the java.util.Observable implementation.Dont be afraid to creat

23、e your own Observable implementation if needed.观察者模式的由来将系统分割成一系列相互协作的类有也存在一些不足:需要维护相关对象间的一致性;为维持一致性而使各类紧密耦合，可能降低其可重用性；没有理由限定依赖于某数据对象的对象数目, 对相同的数据对象可以有任意数目的不同用户界面；观察者模式的意图和适用性意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新适用场合当一个抽象模型有两个方面， 一方面依赖于另一方面。将二者封装在独立对象中以使它们可以独立被改变和复用;一个对象的改变需要同时改变其它对象

24、， 但不知道具体有多少对象有待改变；当一个对象必须通知其它对象,而它又不能假定其它对象是谁。换言之， 不希望这些对象是紧密耦合的；观察者模式的结构观察者模式的参与者Subject：抽象的主题，即被观察的对象Observer:抽象的观察者Concrete Subject：具体被观察对象Concrete Observer：具体的观察者注意：在观察者模式中,Subject通过Attach和Detach方法添加或删除所关联的观察者,并通过Notify进行更新，让每个观察者观察到最新的状态;观察者模式的效果分析应用场景对一个对象状态的更新,需要其他对象同步更新,而且其他对象的数量动态可变；对象仅需要将自

25、己的更新通知给其他对象而不需要知道其他对象细节；优点Subject和Observer之间是松偶合的,可以各自独立改变；Subject在发送广播通知时，无须指定具体的Observer，Observer可以自己决定是否要订阅Subject的通知；高内聚、低偶合；缺陷松偶合导致代码关系不明显，有时可能难以理解；如果一个Subject被大量Observer订阅的话，在广播通知的时候可能会有效率问题；四 Decorator PatternBULLET POINTSInheritance is one form of extension， but not necessarily the best way

26、to achieve flexibility in our designs。In our designs we should allow behavior to be extended without the need to modify existing code.Composition and delegation can often be used to add new behaviors at runtime。The Decorator Pattern provides an alternative to subclassing for extending behavior.The D

27、ecorator Pattern involves a set of decorator classes that are used to wrap concrete components.BULLET POINTSDecorator classes mirror the type of the components they decorate。 （In fact, they are the same type as the components they decorate， either through inheritance or interface implementation.)Decorators change the behavior of their components by adding new functionality before and/or after (or even in place of) method calls to the component.You can wrap a component with any number of decorators.Decorators are typically transparent to the client of the component； that is， u