设计模式 —— 11种行为型设计模式大总结

作者: FeelsChaotic | 来源:发表于2017-03-29 14:33 被阅读302次

逐步完善中。。
来源：《图说设计模式》

行为型模式(Behavioral Pattern)是对在不同的对象之间划分责任和算法的抽象化。

通过行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。在系统运行时，对象并不是孤立的，它们可以通过相互通信与协作完成某些复杂功能，一个对象在运行时也将影响到其他对象的运行。

行为型模式分为类行为型模式和对象行为型模式两种：

类行为型模式：类的行为型模式使用继承关系在几个类之间分配行为，类行为型模式主要通过多态等方式来分配父类与子类的职责。

对象行为型模式：对象行为型模式则使用对象的聚合关联关系来分配行为，对象行为型模式主要是通过对象关联等方式来分配两个或多个类的职责。根据“合成复用原则”，系统中要尽量使用关联关系来取代继承关系，因此大部分行为型设计模式都属于对象行为型设计模式。

包含模式

职责链模式(Chain of Responsibility)
重要程度：3（5为满分）
命令模式(Command)
重要程度：4
解释器模式(Interpreter)
重要程度：1
迭代器模式(Iterator)
重要程度：5
中介者模式(Mediator)
重要程度：2
备忘录模式(Memento)
重要程度：2
观察者模式(Observer)
重要程度：5
状态模式(State)
重要程度：3
策略模式(Strategy)
重要程度：4
模板方法模式(Template Method)
重要程度：3
访问者模式(Visitor)
重要程度：1

一、职责链模式(Chain of Responsibility)

模式动机

模式定义

模式结构

代码分析

模式分析

实例

优点

缺点

应用

扩展

二、命令模式(Command)

模式动机

在软件设计中，我们经常需要向某些对象发送请求，但是并不知道请求的接收者是谁，也不知道被请求的操作是哪个，我们只需在程序运行时指定具体的请求接收者即可，此时，可以使用命令模式来进行设计，使得请求发送者与请求接收者消除彼此之间的耦合，让对象之间的调用关系更加灵活。

命令模式可以对发送者和接收者完全解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只需要知道如何发送请求，而不必知道如何完成请求。这就是命令模式的模式动机。

模式定义

将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。

模式结构

命令模式包含如下角色：

Command: 抽象命令类
ConcreteCommand: 具体命令类
Invoker: 调用者
Receiver: 接收者
Client:客户类

Paste_Image.png

代码分析

/**
 * 命令接口
 */
public interface Command {
  //执行命令
    public void execute();
  //撤销命令
    public void undo();
}

package com.test.patten.command;

/**
 * 命令
 */
public class CreateCommand implements Command{
    private Receiver receiver;//命令接收者
    private String state;
    
    public CreateCommand(Receiver receiver){
        this.receiver = receiver;
    }

    @Override
    public void execute() {
        receiver.action();
    }

    @Override
    public void undo() {
        receiver.unAction();
    }
    
}

/**
 * 命令接收者,命令真正执行人
 */
public class Receiver {
    public void action(){
        System.out.println("执行命令...");
    }
    
    public void unAction(){
        System.out.println("撤销命令...");
    }
}
  /**
     * 调用者
     */
public class Invoker {
    private Command command;//命令对象

    /**
     * 设置命令对象
     * @param command
     */
    public void setCommand(Command command) {
        this.command = command;
    }
    /**
     * 执行命令
     */
    public void runCommand(){
        command.execute();
    }
    /**
     * 撤销命令
     */
    public void unDoCommand(){
        command.undo();
    }
}

  /**
    *客户端
  */
public class Client {
    public static void main(String[] args){
        //创建接受者
        Receiver receiver = new Receiver();
        //创建命令对象，并设置它的接受者
        Command command = new CreateCommand(receiver);
        
        //创建调用者，将命令对象设置进去
        Invoker invoker = new Invoker();
        invoker.setCommand(command);
        
        //这里可以测试一下
        invoker.runCommand();
        invoker.unDoCommand();
    }
}

模式分析

命令模式的本质是对命令进行封装，将发出命令的责任和执行命令的责任分割开。

每一个命令都是一个操作：请求的一方发出请求，要求执行一个操作；接收的一方收到请求，并执行操作。

命令模式允许请求的一方和接收的一方独立开来，使得请求的一方不必知道接收请求的一方的接口，更不必知道请求是怎么被接收，以及操作是否被执行、何时被执行，以及是怎么被执行的。

命令模式使请求本身成为一个对象，这个对象和其他对象一样可以被存储和传递。

命令模式的关键在于引入了抽象命令接口，且发送者针对抽象命令接口编程，只有实现了抽象命令接口的具体命令才能与接收者相关联。

应用

工作队列
线程池
日程安排

三、解释器模式(Interpreter)

模式动机

模式定义

模式结构

代码分析

模式分析

实例

优点

缺点

应用

扩展

四、迭代器模式(Iterator)

模式动机

提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。

模式结构

Paste_Image.png

代码分析

模式分析

实例

优点

缺点

应用

Java集合迭代器

public static void print(Collection coll){  
    Iterator it = coll.iterator();  
    while(it.hasNext()){  
        String str = (String)it.next();  
        System.out.println(str);  
    }  
}

扩展

五、中介者模式(Mediator)

模式动机

模式定义

模式结构

代码分析

模式分析

实例

优点

缺点

应用

扩展

六、备忘录模式(Memento)

模式动机

模式定义

模式结构

代码分析

模式分析

实例

优点

缺点

应用

扩展

七、观察者模式(Observer)

模式动机

建立一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其他对象，其他对象将相应做出反应。在此，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标可以对应多个观察者，而且这些观察者之间没有相互联系，可以根据需要增加和删除观察者，使得系统更易于扩展，这就是观察者模式的模式动机。

模式定义

定义对象间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式又叫做发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。

模式结构

观察者模式包含如下角色：

Subject: 目标
ConcreteSubject: 具体目标
Observer: 观察者
ConcreteObserver: 具体观察者

Paste_Image.png

代码分析

    // 抽象主题类
   
    public abstract class Subject
    {
        private IList<Observer> observers = new List<Observer>();
       // 增加观察者
        public void attach(Observer observer)
        {
            observers.Add(observer);
        }

       // 移除观察者
        public void detach(Observer observer)
        {
            observers.Remove(observer);
        }

    // 向观察者（们）发出通知
        public void notify()
        {
            foreach (Observer o in observers)
            {
                o.Update();
            }
        }
    }

    
    // 抽象观察者类，为所有具体观察者定义一个接口，在得到通知时更新自己
    public abstract class Observer
    {
        public abstract void update();
    }

   // 具体通知者，将有关状态存入具体观察者对象；
    public class ConcreteSubject extend Subject
    {
        private string subjectState;
        //省略set和get方法
    }
    // 具体观察者，实现抽象观察者角色所要求的更新接口，已是本身状态与主题状态相协调
    public class ConcreteObserver extend Observer
    {
        private string observerState;
        private string name;
        private ConcreteSubject subject;

        public ConcreteObserver(ConcreteSubject subject, string name)
        {
            this.subject = subject;
            this.name = name;
        }

      // 实现抽象观察者中的更新操作
        public void update()
        {
            observerState = subject.getSubjectState();
        }
    }
//客户端
static void Main(string[] args)
        {
          
            ConcreteSubject subject = new ConcreteSubject();

            subject.attach(new ConcreteObserver(subject, "Observer A"));
            subject.attach(new ConcreteObserver(subject, "Observer B"));
            subject.attach(new ConcreteObserver(subject, "Observer C"));

            subject.setSubjectState("Ready");
            subject.notify();
        }

优点

观察者模式可以实现表示层和数据逻辑层的分离，并定义了稳定的消息更新传递机制，抽象了更新接口，使得可以有各种各样不同的表示层作为具体观察者角色。

观察者模式在观察目标和观察者之间建立一个抽象的耦合。

观察者模式支持广播通信。

观察者模式符合“开闭原则”的要求。

缺点

如果一个观察目标对象有很多直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。

如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。

观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。

应用

观察者模式在软件开发中应用非常广泛，如某电子商务网站可以在执行发送操作后给用户多个发送商品打折信息，某团队战斗游戏中某队友牺牲将给所有成员提示等等，凡是涉及到一对一或者一对多的对象交互场景都可以使用观察者模式。

扩展

MVC模式

MVC模式是一种架构模式，它包含三个角色：模型(Model)，视图(View)和控制器(Controller)。观察者模式可以用来实现MVC模式，观察者模式中的观察目标就是MVC模式中的模型(Model)，而观察者就是MVC中的视图(View)，控制器(Controller)充当两者之间的中介者(Mediator)。当模型层的数据发生改变时，视图层将自动改变其显示内容。

八、状态模式(State)

模式动机

在很多情况下，一个对象的行为取决于一个或多个动态变化的属性，这样的属性叫做状态，这样的对象叫做有状态的(stateful)对象，这样的对象状态是从事先定义好的一系列值中取出的。当一个这样的对象与外部事件产生互动时，其内部状态就会改变，从而使得系统的行为也随之发生变化。

模式结构

状态模式包含如下角色：

Context: 环境类
State: 抽象状态类
ConcreteState: 具体状态类

Paste_Image.png

应用

使用状态模式可以描述工作流对象（如批文）的状态转换以及不同状态下它所具有的行为。

九、策略模式(Strategy)

模式动机

完成一项任务，往往可以有多种不同的方式，每一种方式称为一个策略，我们可以根据环境或者条件的不同选择不同的策略来完成该项任务。

在软件系统中，有许多算法可以实现某一功能，如查找、排序等，一种常用的方法是硬编码(Hard Coding)在一个类中，如需要提供多种查找算法，可以将这些算法写到一个类中，在该类中提供多个方法，每一个方法对应一个具体的查找算法；当然也可以将这些查找算法封装在一个统一的方法中，通过if…else…等条件判断语句来进行选择。这两种实现方法我们都可以称之为硬编码，如果需要增加一种新的查找算法，需要修改封装算法类的源代码；更换查找算法，也需要修改客户端调用代码。在这个算法类中封装了大量查找算法，该类代码将较复杂，维护较为困难。

为了解决这些问题，可以定义一些独立的类来封装不同的算法，每一个类封装一个具体的算法，在这里，每一个封装算法的类我们都可以称之为策略(Strategy)，为了保证这些策略的一致性，一般会用一个抽象的策略类来做算法的定义，而具体每种算法则对应于一个具体策略类。

模式定义

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

策略模式是一种对象行为型模式。

模式结构

策略模式包含如下角色：

Context: 环境类
Strategy: 抽象策略类
ConcreteStrategy: 具体策略类