首页  思维导图  详情

设计模式

2019-06-17 10:24:39   0  举报





AI智能生成

软件设计模式思维导图

作者其他创作

大纲/内容

行为型设计模式

迭代器模式

定义

将对列表的访问和遍历从列表对象中分离出来，放入到一个独立的迭代器对象中。

角色

aggregate

聚合接口，定义创建相应迭代器对象的接口createIterator

concreteAggregate

封装了一个数据存储结构，实现一个具体的耦合。提供了创建相应迭代器对象的方法createIterator，返回类型为concreteIterator的一个对象

Iterator

迭代器定义访问和遍历元素的接口

concreteIterator（controller）

具体迭代器实现迭代器接口，对该聚合遍历时跟踪当前位置

优点

（1）支持以不同的方式遍历同一个聚合
（2）当修改某一个遍历算法时，不会影响其他的算法
（3）当修改被遍历的聚合结构代码时，若聚合结构没改变则相应的遍历算法也无需改变
（4）简化了聚合的接口

类图

访问者模式

定义

表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作。

类图

角色

visitor

抽象访问者角色，为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色，这样访问者就可以通过该元素角色的特定接口直接访问它

.ConcreteVisitor.

具体访问者角色，实现Visitor声明的接口。

Element

定义一个接受访问操作(accept())，它以一个访问者(Visitor)作为参数。

ConcreteElement

具体元素，实现了抽象元素(Element)所定义的接受操作接口。

ObjectStructure

结构对象角色，这是使用访问者模式必备的角色。它具备以下特性：能枚举它的元素；可以提供一个高层接口以允许访问者访问它的元素；如有需要，可以设计成一个复合对象或者一个聚集（如一个列表或无序集合）。

优点

1、符合单一职责原则：凡是适用访问者模式的场景中，元素类中需要封装在访问者中的操作必定是与元素类本身关系不大且是易变的操作，使用访问者模式一方面符合单一职责原则，另一方面，因为被封装的操作通常来说都是易变的，所以当发生变化时，就可以在不改变元素类本身的前提下，实现对变化部分的扩展。

2、扩展性良好：元素类可以通过接受不同的访问者来实现对不同操作的扩展。

适用情况

1、一个对象结构包含很多类对象，它们有不同的接口，而你想对这些对象实施一些依赖于其具体类的操作。

2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而你想避免让这些操作“污染”这些对象的类。Visitor模式使得你可以将相关的操作集中起来定义在一个类中。

3、当该对象结构被很多应用共享时，用Visitor模式让每个应用仅包含需要用到的操作。

4、定义对象结构的类很少改变，但经常需要在此结构上定义新的操作。改变对象结构类需要重定义对所有访问者的接口，这可能需要很大的代价。如果对象结构类经常改变，那么可能还是在这些类中定义这些操作较好。

命令模式

定义

解除调用者类和接受者类之间的耦合

类图

角色

Command

定义命令的接口，声明执行的方法。

ConcreteCommand

命令接口实现对象，是“虚”的实现；通常会持有接收者，并调用接收者的功能来完成命令要执行的操作。

Receiver：

接收者，真正执行命令的对象。任何类都可能成为一个接收者，只要它能够实现命令要求实现的相应功能。

Invoker

要求命令对象执行请求，通常会持有命令对象，可以持有很多的命令对象。这个是客户端真正触发命令并要求命令执行相应操作的地方，也就是说相当于使用命令对象的入口。

Client

创建具体的命令对象，并且设置命令对象的接收者。注意这个不是我们常规意义上的客户端，而是在组装命令对象和接收者

优点

1.降低对象之间的耦合度。

2.新的命令可以很容易地加入到系统中。

3.可以比较容易地设计一个组合命令。

4.调用同一方法实现不同的功能

缺点

使用命令模式可能会导致某些系统有过多的具体命令类。因为针对每一个命令都需要设计一个具体命令类，因此某些系统可能需要大量具体命令类，这将影响命令模式的使用。

适用环境

1.系统需要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。

2.系统需要在不同的时间指定请求、将请求排队和执行请求。

3.系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作。

4.系统需要将一组操作组合在一起，即支持宏命令。

中介者模式

定义

定义了一个中介对象来封装一系列对象之间的交互关系。中介者使各个对象之间不需要显式地相互引用，从而使耦合性降低，而且可以独立地改变它们之间的交互行为

优点

简化了对象之间的关系，将系统的各个对象之间的相互关系进行封装，将各个同事类解耦，使得系统变为松耦合。
提供系统的灵活性，使得各个同事对象独立而易于复用。

缺点

中介者模式中，中介者角色承担了较多的责任，所以一旦这个中介者对象出现了问题，整个系统将会受到重大的影响。
新增加一个同事类时，不得不去修改抽象中介者类和具体中介者类，此时可以使用观察者模式和状态模式来解决这个问题。

适用场景

一组定义良好的对象，现在要进行复杂的相互通信。
想通过一个中间类来封装多个类中的行为，而又不想生成太多的子类。

类图

角色

mediator

中介者接口

concreteMediator

具体的中介者

colleague

参与者对象接口

concreteColleague

具体的参与者

策略模式

定义

策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

类图

角色

Context（环境类/上下文类）

1、需要使用ConcreteStrategy提供的算法。
　　2、内部维护一个Strategy的实例。
　　3、负责动态设置运行时Strategy具体的实现算法。
　　4、负责跟Strategy之间的交互和数据传递。

　　Strategy(抽象策略类)

定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，Context使用这个接口调用不同的算法，一般使用接口或抽象类实现。

　ConcreteStrategy(具体策略类)

实现了Strategy定义的接口，提供具体的算法实现

适用场景

1、多个类只区别在表现行为不同，可以使用Strategy模式，在运行时动态选择具体要执行的行为。(例如FlyBehavior和QuackBehavior)
　　2、需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现。(例如FlyBehavior和QuackBehavior的具体实现可任意变化或扩充)
　　3、对客户(Duck)隐藏具体策略(算法)的实现细节，彼此完全独立。

优点

1、提供了一种替代继承的方法，而且既保持了继承的优点(代码重用)还比继承更灵活(算法独立，可以任意扩展)。
　　2、避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。
　　3、遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。

缺点

因为每个具体策略类都会产生一个新类，所以会增加系统需要维护的类的数量。

状态模式

定义

当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。

适用场景

1.一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为。

2.一个操作中含有庞大的多分支结构，并且这些分支决定于对象的状态。

类图

角色

context

定义了与客户程序的接口，保持了一个concreteState的代表现在状态的实例

state

定义了状态接口，它的子类封装了在各个不同状态下的行为

concreteState

封装了在各种不同状态下的行为

优点

（1）因为各个状态相关的代码都被封装在各子类中，所以易扩展易修改
（2）将不同状态封装到不同的子类中使得状态的迁移很明确，并且可以防止context类将其弄混乱

创建型设计模式

工厂模式

简单工厂模式

定义

由一个工厂对象决定创建出哪一种产品类的实例

工厂方法模式

定义

定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，让类的实例化推迟到子类中进行

抽象工厂模式

定义

抽象工厂模式可以向客户端提供一个接口，使客户端在不必指定产品的具体的情况下，创建多个产品族中的产品对象。根据里氏替换原则，任何接受父类型的地方，都应当能够接受子类型

生成器模式

定义

可以将一个产品的内部表象与产品的生成过程分割开来，从而可以使一个建造过程生成具有不同的内部表象的产品对象

单例模式

定义

一个类有且仅有一个实例，并且自行实例化向整个系统提供

结构性设计模式

组合模式

定义

将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性

适配器模式

类适配器模式

定义

用一个target接口声明所有需要的方法，用另一个adapter类实现接口中的所有的方法，同时继承adaptee类

类图

对象适配器模式

定义

与类适配器模式相似，不同的是调用adapett类中的方法

外观模式

定义

用来隐藏一个软件系统的所有内部细节，只提供给客户一个外观类或者接口类，客户类只需调用外观类的方法即可，不必了解内部细节

类图

角色

Facade

外观类，被客户角色所调用，了解所有子系统的功能，内部根据客户已有需求预订了几种功能组合

clients

调用外观角色来完成要得到的功能

subSystem

实现子系统的功能，没有任何外观角色和客户角色的信息和链接

优点

（1）实现了子系统与客户端之间的松耦合关系。

（2）客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起来更加容易。

适用场景

在以下情况下可以考虑使用外观模式：

(1)设计初期阶段，应该有意识的将不同层分离，层与层之间建立外观模式。

(2) 开发阶段，子系统越来越复杂，增加外观模式提供一个简单的调用接口。

(3) 维护一个大型遗留系统的时候，可能这个系统已经非常难以维护和扩展，但又包含非常重要的功能，为其开发一个外观类，以便新系统与其交互。

桥接模式

定义

将层次类拆分为抽象部分和实现部分，使其可以独立变化

类图