行为型模式用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务,它涉及算法与对象间职责的分配。
行为型模式分为类行为模式和对象行为模式,前者采用继承机制来在类间分派行为,后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低,满足“合成复用原则”,所以对象行为模式比类行为模式具有更大的灵活性。
行为型模式是 GoF 设计模式中最为庞大的一类,它包含以下 11 种模式。
- 模板方法(Template Method)模式:定义一个操作中的算法骨架,将算法的一些步骤延迟到子类中,使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
- 策略(Strategy)模式:定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的改变不会影响使用算法的客户。
- 命令(Command)模式:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。
- 职责链(Chain of Responsibility)模式:把请求从链中的一个对象传到下一个对象,直到请求被响应为止。通过这种方式去除对象之间的耦合。
- 状态(State)模式:允许一个对象在其内部状态发生改变时改变其行为能力。
- 观察者(Observer)模式:多个对象间存在一对多关系,当一个对象发生改变时,把这种改变通知给其他多个对象,从而影响其他对象的行为。
- 中介者(Mediator)模式:定义一个中介对象来简化原有对象之间的交互关系,降低系统中对象间的耦合度,使原有对象之间不必相互了解。
- 迭代器(Iterator)模式:提供一种方法来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。
- 访问者(Visitor)模式:在不改变集合元素的前提下,为一个集合中的每个元素提供多种访问方式,即每个元素有多个访问者对象访问。
- 备忘录(Memento)模式:在不破坏封装性的前提下,获取并保存一个对象的内部状态,以便以后恢复它。
- 解释器(Interpreter)模式:提供如何定义语言的文法,以及对语言句子的解释方法,即解释器。
1.模板方法模式
程序员常常会遇到这种情况:设计一个系统时知道了算法所需的关键步骤,而且确定了这些步骤的执行顺序,但某些步骤的具体实现还未知,或者说某些步骤的实现与具体的环境相关。
在生活中也一样, 我们每天起床 刷牙 吃饭, 但是吃饭每个人吃的东西可能都不一样, 但是顺序是定的 .模板方法也就是为了解决上述问题的
模式的定义与特点
模板方法(Template Method)模式的定义如下: 定义一个操作中的算法骨架(执行顺序之类的),将不变的放在骨架中, 变化的放到子类中去实现
说白了就是 客户访问接口, 接口的实现类里会设计好执行顺序,有一些是这个实现类固有的方法, 有一些是需要子类去重写的, 然后运行这些方法, 子类的方法还可以改变父类的方法(被改变的父类方法就叫钩子方法)
优点:
1.它封装了不变部分,扩展可变部分。
2.它在父类中提取了公共的部分代码,便于代码复用
3.部分方法是由子类实现的,因此子类可以通过扩展方式增加相应的功能,符合开闭原则。
缺点:
1.每一个子类都会增加系统的复杂性,而他的功能扩展就是靠子类
2.父类的方法由子类实现,这是一种反向控制的结构, 反向控制的可读性差
3.由于继承的关系, 导致如果修改父类的抽象方法, 那么每个子类也都得改
模式的结构与实现
1)抽象类/抽象模板(Abstract Class)
抽象模板类,负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。这些方法的定义如下。
① 模板方法:定义了算法的骨架,按某种顺序调用其包含的基本方法。
② 基本方法:是整个算法中的一个步骤,包含以下几种类型。
- 抽象方法:在抽象类中声明,由具体子类实现。
- 具体方法:在抽象类中已经实现,在具体子类中可以继承或重写它。
- 钩子方法:在抽象类中已经实现,包括用于判断的逻辑方法和需要子类重写的空方法两种。
2)具体子类/具体实现(Concrete Class)
具体实现类,实现抽象类中所定义的抽象方法和钩子方法,它们是一个顶级逻辑的一个组成步骤。

public class TemplateMethodPattern {public static void main(String[] args) {AbstractClass tm = new ConcreteClass();tm.TemplateMethod();}}//抽象类abstract class AbstractClass {//模板方法public void TemplateMethod() {SpecificMethod();abstractMethod1();abstractMethod2();}//具体方法public void SpecificMethod() {System.out.println("抽象类中的具体方法被调用...");}//抽象方法1public abstract void abstractMethod1();//抽象方法2public abstract void abstractMethod2();}//具体子类class ConcreteClass extends AbstractClass {public void abstractMethod1() {System.out.println("抽象方法1的实现被调用...");}public void abstractMethod2() {System.out.println("抽象方法2的实现被调用...");}}执行结果为抽象类中的具体方法被调用...抽象方法1的实现被调用...抽象方法2的实现被调用...
模式的扩展
在模板方法模式中,基本方法包含:抽象方法、具体方法和钩子方法,正确使用“钩子方法”可以使得子类控制父类的行为。如下面例子中,可以通过在具体子类中重写钩子方法 HookMethod1() 和 HookMethod2() 来改变抽象父类中的运行结果,其结构图如图 3 所示。

public class HookTemplateMethod {public static void main(String[] args) {HookAbstractClass tm = new HookConcreteClass();tm.TemplateMethod();}}//含钩子方法的抽象类abstract class HookAbstractClass {//模板方法public void TemplateMethod() {abstractMethod1();HookMethod1();if (HookMethod2()) {SpecificMethod();}abstractMethod2();}//具体方法public void SpecificMethod() {System.out.println("抽象类中的具体方法被调用...");}//钩子方法1public void HookMethod1() {}//钩子方法2public boolean HookMethod2() {return true;}//抽象方法1public abstract void abstractMethod1();//抽象方法2public abstract void abstractMethod2();}//含钩子方法的具体子类class HookConcreteClass extends HookAbstractClass {public void abstractMethod1() {System.out.println("抽象方法1的实现被调用...");}public void abstractMethod2() {System.out.println("抽象方法2的实现被调用...");}public void HookMethod1() {System.out.println("钩子方法1被重写...");}public boolean HookMethod2() {return false;}}抽象方法1的实现被调用...钩子方法1被重写...抽象方法2的实现被调用...
上面这种就是通过子类去重写钩子方法,进而来控制其父类
2.策略模式
在生活中 假如我们放假回老家, 会有很多种策略, 坐飞机,坐火车 ,坐大巴等 每一种交通方式都是不同的策略
带代码中,针对客户的不同需求会有不同的策略,但是并不改变客户对客户端感知,这便是策略模式的用意
策略模式的定义与特点
策略(Strategy)模式的定义:该模式定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式,它通过对算法进行封装,把使用算法的责任和算法的实现分割开来,并委派给不同的对象对这些算法进行管理。
策略模式的重点不是创造对象,而是组织对象
说白了就是: 一个接口有不同的实现类,通过环境类(也可以通过xml,hashMap之类的来控制对不同的实现类的访问)来调用不同实现类的同名方法达到实现不同策略的目的. 利用的其实就是多态性,接口的实现类不同 方法就会不同
中心思想就是:一个接口针对不同的情况给出不同的方法, 用实现类来实现
策略模式的主要优点如下。
- 多重条件语句不易维护,而使用策略模式可以避免使用多重条件语句,如 if…else 语句、switch…case 语句。
- 策略模式提供了一系列的可供重用的算法族,恰当使用继承可以把算法族的公共代码转移到父类里面,从而避免重复的代码。
- 策略模式可以提供相同行为的不同实现,客户可以根据不同时间或空间要求选择不同的。
- 策略模式提供了对开闭原则的完美支持,可以在不修改原代码的情况下,灵活增加新算法。
- 策略模式把算法的使用放到环境类中,而算法的实现移到具体策略类中,实现了二者的分离。
其主要缺点如下。
- 客户端必须理解所有策略算法的区别,以便适时选择恰当的算法类。
- 策略模式造成很多的策略类,增加维护难度。
策略模式的结构与实现
1. 模式的结构
策略模式的主要角色如下。
- 抽象策略(Strategy)类:定义了一个公共接口,各种不同的算法以不同的方式实现这个接口,环境角色使用这个接口调用不同的算法,一般使用接口或抽象类实现。
- 具体策略(Concrete Strategy)类:实现了抽象策略定义的接口,提供具体的算法实现。
- 环境(Context)类:持有一个策略类的引用,最终给客户端调用。

2. 模式的实现
策略模式的实现代码如下:
public class StrategyPattern {public static void main(String[] args) {Context c = new Context();Strategy s = new ConcreteStrategyA();c.setStrategy(s);c.strategyMethod();System.out.println("-----------------");s = new ConcreteStrategyB();c.setStrategy(s);c.strategyMethod();}}//抽象策略类interface Strategy {public void strategyMethod(); //策略方法}//具体策略类Aclass ConcreteStrategyA implements Strategy {public void strategyMethod() {System.out.println("具体策略A的策略方法被访问!");}}//具体策略类Bclass ConcreteStrategyB implements Strategy {public void strategyMethod() {System.out.println("具体策略B的策略方法被访问!");}}//环境类class Context {private Strategy strategy;public Strategy getStrategy() {return strategy;}public void setStrategy(Strategy strategy) {this.strategy = strategy;}public void strategyMethod() {strategy.strategyMethod();}}
策略模式的扩展
在一个使用策略模式的系统中,当存在的策略很多时,客户端管理所有策略算法将变得很复杂,如果在环境类中使用策略工厂模式来管理这些策略类将大大减少客户端的工作复杂度,其结构图如图 5 所示。
3.命令模式
在软件开发系统中,“方法的请求者”与“方法的实现者”之间经常存在紧密的耦合关系,这不利于软件功能的扩展与维护,“如何将方法的请求者与实现者解耦?”变得很重要,命令模式就能很好地解决这个问题。
在生活中 我们用遥控器 控制电视, 这就是请求与实现者的分离, 我们是请求者, 电视机是接收者,我们改变自己并不影响电视机使用,我们通过中间件(遥控器)来控制电视机, 在程序中我们能做到这样就可达到我们命令模式的要求了
也就是说白了, 你改变调用者的代码不会影响到接收者 这便达到了隔离的目的,利用聚合关系来解耦
命令模式的定义与特点
命令(Command)模式的定义如下:将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通,这样方便将命令对象进行储存、传递、调用、增加与管理。
命令模式的主要优点如下。
- 通过引入中间件(抽象接口)降低系统的耦合度。
- 扩展性良好,增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类,且满足“开闭原则”。
- 可以实现宏命令。命令模式可以与组合模式结合,将多个命令装配成一个组合命令,即宏命令。
- 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合,实现命令的撤销与恢复。
- 可以在现有命令的基础上,增加额外功能。比如日志记录,结合装饰器模式会更加灵活。
其缺点是:
- 可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类,这会增加系统的复杂性。
- 命令模式的结果其实就是接收方的执行结果,但是为了以命令的形式进行架构、解耦请求与实现,引入了额外类型结构(引入了请求方与抽象命令接口),增加了理解上的困难。不过这也是设计模式的通病,抽象必然会额外增加类的数量,代码抽离肯定比代码聚合更加难理解。
命令模式的结构与实现
可以将系统中的相关操作抽象成命令,使调用者与实现者相关分离,其结构如下。
1. 模式的结构
命令模式包含以下主要角色。
- 抽象命令类(Command)角色:声明执行命令的接口,拥有执行命令的抽象方法 execute()。例如遥控器
- 具体命令类(Concrete Command)角色:是抽象命令类的具体实现类,它拥有接收者对象,并通过调用接收者的功能来完成命令要执行的操作。例如开机按钮
- 实现者/接收者(Receiver)角色:执行命令功能的相关操作,是具体命令对象业务的真正实现者。 电视机
- 调用者/请求者(Invoker)角色:是请求的发送者,它通常拥有很多的命令对象,并通过访问命令对象来执行相关请求,它不直接访问接收者。 我们

2. 模式的实现
命令模式的代码如下:
package command;public class CommandPattern {public static void main(String[] args) {Command cmd = new ConcreteCommand();Invoker ir = new Invoker(cmd);System.out.println("客户访问调用者的call()方法...");ir.call();}}//调用者class Invoker {private Command command;public Invoker(Command command) {this.command = command;}public void setCommand(Command command) {this.command = command;}public void call() {System.out.println("调用者执行命令command...");command.execute();}}//抽象命令interface Command {public abstract void execute();}//具体命令class ConcreteCommand implements Command {private Receiver receiver;ConcreteCommand() {receiver = new Receiver();}public void execute() {receiver.action();}}//接收者class Receiver {public void action() {System.out.println("接收者的action()方法被调用...");}}执行结果客户访问调用者的call()方法...调用者执行命令command...接收者的action()方法被调用...
从代码中可以看到 你不管怎么改变你的调用者代码 ,都不会影响接收者, 这就是隔离了
命令模式的应用场景
当系统的某项操作具备命令语义,且命令实现不稳定(变化)时,可以通过命令模式解耦请求与实现。使用抽象命令接口使请求方的代码架构稳定,封装接收方具体命令的实现细节。接收方与抽象命令呈现弱耦合(内部方法无需一致),具备良好的扩展性。
命令模式通常适用于以下场景。
- 请求调用者需要与请求接收者解耦时,命令模式可以使调用者和接收者不直接交互。
- 系统随机请求命令或经常增加、删除命令时,命令模式可以方便地实现这些功能。
- 当系统需要执行一组操作时,命令模式可以定义宏命令来实现该功能。
- 当系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作时,可以将命令对象存储起来,采用备忘录模式来实现。
命令模式的扩展
在软件开发中,有时将命令模式与前面学的组合模式联合使用,这就构成了宏命令模式,也叫组合命令模式。宏命令包含了一组命令,它充当了具体命令与调用者的双重角色,执行它时将递归调用它所包含的所有命令,其具体结构图如图 3 所示。

package command;import java.util.ArrayList;public class CompositeCommandPattern {public static void main(String[] args) {AbstractCommand cmd1 = new ConcreteCommand1();AbstractCommand cmd2 = new ConcreteCommand2();CompositeInvoker ir = new CompositeInvoker();ir.add(cmd1);ir.add(cmd2);System.out.println("客户访问调用者的execute()方法...");ir.execute();}}//抽象命令interface AbstractCommand {public abstract void execute();}//树叶构件: 具体命令1class ConcreteCommand1 implements AbstractCommand {private CompositeReceiver receiver;ConcreteCommand1() {receiver = new CompositeReceiver();}public void execute() {receiver.action1();}}//树叶构件: 具体命令2class ConcreteCommand2 implements AbstractCommand {private CompositeReceiver receiver;ConcreteCommand2() {receiver = new CompositeReceiver();}public void execute() {receiver.action2();}}//树枝构件: 调用者class CompositeInvoker implements AbstractCommand {private ArrayList<AbstractCommand> children = new ArrayList<AbstractCommand>();public void add(AbstractCommand c) {children.add(c);}public void remove(AbstractCommand c) {children.remove(c);}public AbstractCommand getChild(int i) {return children.get(i);}public void execute() {for (Object obj : children) {((AbstractCommand) obj).execute();}}}//接收者class CompositeReceiver {public void action1() {System.out.println("接收者的action1()方法被调用...");}public void action2() {System.out.println("接收者的action2()方法被调用...");}}
4.责任链模式(职责链模式)
在现实的生活中我们要做一件事 会有很多步骤, 比如 我们要去看胃病, 要先挂号,再去取挂号单,再去对应的诊室门诊,最后还要去取药, 这一环接着一环 都需要我们知道下一步要干嘛
代码中, 一个请求在传入处理器后要经经历一系列的操作最终成为预期结果, 如果请求每次访问一次处理器都要去手动设置下一个要访问哪个处理器,这样很费劲, 因此就有了责任链模式, 请求跟实现分离, 你无需关心它到底要怎么走, 它会根据自身的条件来判断要去哪个处理器 这便是责任链
模式的定义与特点
责任链(Chain of Responsibility)模式的定义:为了避免请求发送者与多个请求处理者耦合在一起,于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。
在责任链模式中,客户只需要将请求发送到设置好的责任链上即可(这个责任链需要单独设置),无须关心请求的处理细节和请求的传递过程,请求会自动进行传递。所以责任链将请求的发送者和请求的处理者解耦了。
说白了,就是你只要传进来请求, 程序自动帮你调用不同的handler帮你处理了, 至于怎么处理,顺序怎样 你不必关心,能做到这样,让其按照链式自行运行,便是实现了责任链模式了, 拓展就通过继承(重写抽象方法)或者实现接口来拓展, 请求会带参数, 每个处理器都能判断参数来判断是否满足本handler的执行要求
责任链跟策略的区别: 策略模式是平铺的感觉,环境控制类根据条件来调用不同的handler来处理, 而责任链模式更类似于是纵向的,它主要的作用是减少if else /switch catch, 它每个handler会都会指向下一个handler,直到找到能处理该请求的handler.,而策略不一样,策略的handler不会指向下一个, 而是直接进行处理
责任链模式是一种对象行为型模式,其主要优点如下。
- 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构,发送者和接收者也无须拥有对方的明确信息。
- 增强了系统的可扩展性。可以根据需要增加新的请求处理类,满足开闭原则。
- 增强了给对象指派职责的灵活性。当工作流程发生变化,可以动态地改变链内的成员或者调动它们的次序,也可动态地新增或者删除责任。
- 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用,不需保持其他所有处理者的引用,这避免了使用众多的 if 或者 if···else 语句。
- 责任分担。每个类只需要处理自己该处理的工作,不该处理的传递给下一个对象完成,明确各类的责任范围,符合类的单一职责原则。
其主要缺点如下。
- 不能保证每个请求一定被处理。由于一个请求没有明确的接收者,所以不能保证它一定会被处理,该请求可能一直传到链的末端都得不到处理。
- 对比较长的职责链,请求的处理可能涉及多个处理对象,系统性能将受到一定影响。
- 职责链建立的合理性要靠客户端来保证,增加了客户端的复杂性,可能会由于职责链的错误设置而导致系统出错,如可能会造成循环调用。
模式的结构与实现
1. 模式的结构
职责链模式主要包含以下角色。
- 抽象处理者(Handler)角色:定义一个处理请求的接口,包含抽象处理方法和一个后继连接。
- 具体处理者(Concrete Handler)角色:实现抽象处理者的处理方法,判断能否处理本次请求,如果可以处理请求则处理,否则将该请求转给它的后继者。
- 客户类(Client)角色:创建处理链,并向链头的具体处理者对象提交请求,它不关心处理细节和请求的传递过程
责任链模式的本质是解耦请求与处理,让请求在处理链中能进行传递与被处理;理解责任链模式应当理解其模式,而不是其具体实现。责任链模式的独到之处是将其节点处理者组合成了链式结构,并允许节点自身决定是否进行请求处理或转发,相当于让请求流动起来。

2. 模式的实现
职责链模式的实现代码如下:
package chainOfResponsibility;public class ChainOfResponsibilityPattern {public static void main(String[] args) {//组装责任链Handler handler1 = new ConcreteHandler1();Handler handler2 = new ConcreteHandler2();handler1.setNext(handler2);//提交请求handler1.handleRequest("two");}}//抽象处理者角色abstract class Handler {private Handler next;public void setNext(Handler next) {this.next = next;}public Handler getNext() {return next;}//处理请求的方法public abstract void handleRequest(String request);}//具体处理者角色1class ConcreteHandler1 extends Handler {public void handleRequest(String request) {if (request.equals("one")) {System.out.println("具体处理者1负责处理该请求!");} else {if (getNext() != null) {getNext().handleRequest(request);} else {System.out.println("没有人处理该请求!");}}}}//具体处理者角色2class ConcreteHandler2 extends Handler {public void handleRequest(String request) {if (request.equals("two")) {System.out.println("具体处理者2负责处理该请求!");} else {if (getNext() != null) {getNext().handleRequest(request);} else {System.out.println("没有人处理该请求!");}}}}程序运行结果如下:具体处理者2负责处理该请求!
在上面代码中,我们把消息硬编码为 String 类型,而在真实业务中,消息是具备多样性的,可以是 int、String 或者自定义类型。因此,在上面代码的基础上,可以对消息类型进行抽象 Request,增强了消息的兼容性。
模式的扩展
职责链模式存在以下两种情况。
- 纯的职责链模式:一个请求必须被某一个处理者对象所接收,且一个具体处理者对某个请求的处理只能采用以下两种行为之一:自己处理(承担责任);把责任推给下家处理。
- 不纯的职责链模式:允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况,且一个请求可以最终不被任何接收端对象所接收。
5.状态模式
在软件开发过程中,应用程序中的部分对象可能会根据不同的情况做出不同的行为,我们把这种对象称为有状态的对象,而把影响对象行为的一个或多个动态变化的属性称为状态。
在我们的代码中有时候会根据if else 或 switch case 来判断状态 来决定不同的行为, 这样的扩展性不强, 而状态模式 就是让对象具有状态的同时具有行为, 你传进来的对象对应着不同状态下的行为,就解决了这样的问题
本文中的方法, 就是通过环境类聚合状态接口, 然后传不不同的接口实现类,实现类自带状态跟行为
状态模式的定义与特点
状态(State)模式的定义:对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。
状态模式是一种对象行为型模式,其主要优点如下。
- 结构清晰,状态模式将与特定状态相关的行为局部化到一个状态中,并且将不同状态的行为分割开来,满足“单一职责原则”。
- 将状态转换显示化,减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确,且减少对象间的相互依赖。
- 状态类职责明确,有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。
状态模式的主要缺点如下。
- 状态模式的使用必然会增加系统的类与对象的个数。
- 状态模式的结构与实现都较为复杂,如果使用不当会导致程序结构和代码的混乱。
- 状态模式对开闭原则的支持并不太好,对于可以切换状态的状态模式,增加新的状态类需要修改那些负责状态转换的源码,否则无法切换到新增状态,而且修改某个状态类的行为也需要修改对应类的源码。
状态模式的结构与实现
1. 模式的结构
状态模式包含以下主要角色。
- 环境类(Context)角色:也称为上下文,它定义了客户端需要的接口,内部维护一个当前状态,并负责具体状态的切换。
- 抽象状态(State)角色:定义一个接口,用以封装环境对象中的特定状态所对应的行为,可以有一个或多个行为。
- 具体状态(Concrete State)角色:实现抽象状态所对应的行为,并且在需要的情况下进行状态切换。

2. 模式的实现
状态模式的实现代码如下:
public class StatePatternClient {public static void main(String[] args) {Context context = new Context(); //创建环境context.Handle(); //处理请求context.Handle();context.Handle();context.Handle();}}//环境类class Context {private State state;//定义环境类的初始状态public Context() {this.state = new ConcreteStateA();}//设置新状态public void setState(State state) {this.state = state;}//读取状态public State getState() {return (state);}//对请求做处理public void Handle() {state.Handle(this);}}//抽象状态类abstract class State {public abstract void Handle(Context context);}//具体状态A类class ConcreteStateA extends State {public void Handle(Context context) {System.out.println("当前状态是 A.");context.setState(new ConcreteStateB());}}//具体状态B类class ConcreteStateB extends State {public void Handle(Context context) {System.out.println("当前状态是 B.");context.setState(new ConcreteStateA());}}运行结果当前状态是 A.当前状态是 B.当前状态是 A.当前状态是 B.
【例2】用“状态模式”设计一个多线程的状态转换程序。
分析:多线程存在 5 种状态,分别为新建状态、就绪状态、运行状态、阻塞状态和死亡状态,各个状态当遇到相关方法调用或事件触发时会转换到其他状态,其状态转换规律如图 3 所示。

现在先定义一个抽象状态类(TheadState),然后为图 3 所示的每个状态设计一个具体状态类,它们是新建状态(New)、就绪状态(Runnable )、运行状态(Running)、阻塞状态(Blocked)和死亡状态(Dead),每个状态中有触发它们转变状态的方法,环境类(ThreadContext)中先生成一个初始状态(New),并提供相关触发方法,图 4 所示是线程状态转换程序的结构图。

public class ScoreStateTest {public static void main(String[] args) {ThreadContext context = new ThreadContext();context.start();context.getCPU();context.suspend();context.resume();context.getCPU();context.stop();}}//环境类class ThreadContext {private ThreadState state;ThreadContext() {state = new New();}public void setState(ThreadState state) {this.state = state;}public ThreadState getState() {return state;}public void start() {((New) state).start(this);}public void getCPU() {((Runnable) state).getCPU(this);}public void suspend() {((Running) state).suspend(this);}public void stop() {((Running) state).stop(this);}public void resume() {((Blocked) state).resume(this);}}//抽象状态类:线程状态abstract class ThreadState {protected String stateName; //状态名}//具体状态类:新建状态class New extends ThreadState {public New() {stateName = "新建状态";System.out.println("当前线程处于:新建状态.");}public void start(ThreadContext hj) {System.out.print("调用start()方法-->");if (stateName.equals("新建状态")) {hj.setState(new Runnable());} else {System.out.println("当前线程不是新建状态,不能调用start()方法.");}}}//具体状态类:就绪状态class Runnable extends ThreadState {public Runnable() {stateName = "就绪状态";System.out.println("当前线程处于:就绪状态.");}public void getCPU(ThreadContext hj) {System.out.print("获得CPU时间-->");if (stateName.equals("就绪状态")) {hj.setState(new Running());} else {System.out.println("当前线程不是就绪状态,不能获取CPU.");}}}//具体状态类:运行状态class Running extends ThreadState {public Running() {stateName = "运行状态";System.out.println("当前线程处于:运行状态.");}public void suspend(ThreadContext hj) {System.out.print("调用suspend()方法-->");if (stateName.equals("运行状态")) {hj.setState(new Blocked());} else {System.out.println("当前线程不是运行状态,不能调用suspend()方法.");}}public void stop(ThreadContext hj) {System.out.print("调用stop()方法-->");if (stateName.equals("运行状态")) {hj.setState(new Dead());} else {System.out.println("当前线程不是运行状态,不能调用stop()方法.");}}}//具体状态类:阻塞状态class Blocked extends ThreadState {public Blocked() {stateName = "阻塞状态";System.out.println("当前线程处于:阻塞状态.");}public void resume(ThreadContext hj) {System.out.print("调用resume()方法-->");if (stateName.equals("阻塞状态")) {hj.setState(new Runnable());} else {System.out.println("当前线程不是阻塞状态,不能调用resume()方法.");}}}//具体状态类:死亡状态class Dead extends ThreadState {public Dead() {stateName = "死亡状态";System.out.println("当前线程处于:死亡状态.");}}运行结果如下当前线程处于:新建状态.调用start()方法-->当前线程处于:就绪状态.获得CPU时间-->当前线程处于:运行状态.调用suspend()方法-->当前线程处于:阻塞状态.调用resume()方法-->当前线程处于:就绪状态.获得CPU时间-->当前线程处于:运行状态.调用stop()方法-->当前线程处于:死亡状态.
状态模式的应用场景
通常在以下情况下可以考虑使用状态模式。
- 当一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为时,就可以考虑使用状态模式。
- 一个操作中含有庞大的分支结构,并且这些分支决定于对象的状态时。
状态模式的扩展
在有些情况下,可能有多个环境对象需要共享一组状态,这时需要引入享元模式,将这些具体状态对象放在集合中供程序共享,其结构图如图 5 所示。
分析:共享状态模式的不同之处是在环境类中增加了一个 HashMap 来保存相关状态(这样就不用重新创建新对象了),当需要某种状态时可以从中获取,其程序代码如下package state;import java.util.HashMap;public class FlyweightStatePattern {public static void main(String[] args) {ShareContext context = new ShareContext(); //创建环境context.Handle(); //处理请求context.Handle();context.Handle();context.Handle();}}//环境类class ShareContext {private ShareState state;private HashMap<String, ShareState> stateSet = new HashMap<String, ShareState>();public ShareContext() {state = new ConcreteState1();stateSet.put("1", state);state = new ConcreteState2();stateSet.put("2", state);state = getState("1");}//设置新状态public void setState(ShareState state) {this.state = state;}//读取状态public ShareState getState(String key) {ShareState s = (ShareState) stateSet.get(key);return s;}//对请求做处理public void Handle() {state.Handle(this);}}//抽象状态类abstract class ShareState {public abstract void Handle(ShareContext context);}//具体状态1类class ConcreteState1 extends ShareState {public void Handle(ShareContext context) {System.out.println("当前状态是: 状态1");context.setState(context.getState("2"));}}//具体状态2类class ConcreteState2 extends ShareState {public void Handle(ShareContext context) {System.out.println("当前状态是: 状态2");context.setState(context.getState("1"));}}结果当前状态是: 状态1当前状态是: 状态2当前状态是: 状态1当前状态是: 状态2
拓展
状态模式与责任链模式的区别
状态模式和责任链模式都能消除 if-else 分支过多的问题。但在某些情况下,状态模式中的状态可以理解为责任,那么在这种情况下,两种模式都可以使用。
从定义来看,状态模式强调的是一个对象内在状态的改变,而责任链模式强调的是外部节点对象间的改变。
从代码实现上来看,两者最大的区别就是状态模式的各个状态对象知道自己要进入的下一个状态对象,而责任链模式并不清楚其下一个节点处理对象,因为链式组装由客户端负责。
状态模式与策略模式的区别
状态模式和策略模式的 UML 类图架构几乎完全一样,但两者的应用场景是不一样的。策略模式的多种算法行为择其一都能满足,彼此之间是独立的,用户可自行更换策略算法,而状态模式的各个状态间存在相互关系,彼此之间在一定条件下存在自动切换状态的效果,并且用户无法指定状态,只能设置初始状态。
6.观察者模式
观察者(Observer)模式的定义:指多个对象间存在一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式,它是对象行为型模式。
思想便是 目标的具体实现类发出通知, 订阅类接受通知执行代码(看起来 就像他观察到了变化而变化),将原来耦合的两个关系 分割开来, 分割成独立的部分,然后通过消息来控制另一方跟着改变方而改变.这样能松耦合
目标类发生变化,观察类观察到目标类变化而变化
观察者模式是一种对象行为型模式,其主要优点如下。
- 降低了目标与观察者之间的耦合关系,两者之间是抽象耦合关系。符合依赖倒置原则。
- 目标与观察者之间建立了一套触发机制。
它的主要缺点如下。
- 目标与观察者之间的依赖关系并没有完全解除,而且有可能出现循环引用。
- 当观察者对象很多时,通知的发布会花费很多时间,影响程序的效率。
模式的结构与实现
实现观察者模式时要注意具体目标对象和具体观察者对象之间不能直接调用,否则将使两者之间紧密耦合起来,这违反了面向对象的设计原则。
1. 模式的结构
观察者模式的主要角色如下。
- 抽象主题(Subject)角色:也叫抽象目标类,它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法,以及通知所有观察者的抽象方法。
- 具体主题(Concrete Subject)角色:也叫具体目标类,它实现抽象目标中的通知方法,当具体主题的内部状态发生改变时,通知所有注册过的观察者对象。
- 抽象观察者(Observer)角色:它是一个抽象类或接口,它包含了一个更新自己的抽象方法,当接到具体主题的更改通知时被调用。
- 具体观察者(Concrete Observer)角色:实现抽象观察者中定义的抽象方法,以便在得到目标的更改通知时更新自身的状态。
观察者模式的结构图如图 1 所示

2. 模式的实现
观察者模式的实现代码如下:
package net.biancheng.c.observer;import java.util.*;public class ObserverPattern {public static void main(String[] args) {Subject subject = new ConcreteSubject();Observer obs1 = new ConcreteObserver1();Observer obs2 = new ConcreteObserver2();subject.add(obs1);subject.add(obs2);subject.notifyObserver();}}//抽象目标abstract class Subject {protected List<Observer> observers = new ArrayList<Observer>();//增加观察者方法public void add(Observer observer) {observers.add(observer);}//删除观察者方法public void remove(Observer observer) {observers.remove(observer);}public abstract void notifyObserver(); //通知观察者方法}//具体目标class ConcreteSubject extends Subject {public void notifyObserver() {System.out.println("具体目标发生改变...");System.out.println("--------------");for (Object obs : observers) {((Observer) obs).response();}}}//抽象观察者interface Observer {void response(); //反应}//具体观察者1class ConcreteObserver1 implements Observer {public void response() {System.out.println("具体观察者1作出反应!");}}//具体观察者1class ConcreteObserver2 implements Observer {public void response() {System.out.println("具体观察者2作出反应!");}}具体目标发生改变...--------------具体观察者1作出反应!具体观察者2作出反应!
模式的应用场景
在软件系统中,当系统一方行为依赖另一方行为的变动时,可使用观察者模式松耦合联动双方,使得一方的变动可以通知到感兴趣的另一方对象,从而让另一方对象对此做出响应。
通过前面的分析与应用实例可知观察者模式适合以下几种情形。
- 对象间存在一对多关系,一个对象的状态发生改变会影响其他对象。
- 当一个抽象模型有两个方面,其中一个方面依赖于另一方面时,可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
- 实现类似广播机制的功能,不需要知道具体收听者,只需分发广播,系统中感兴趣的对象会自动接收该广播。
- 多层级嵌套使用,形成一种链式触发机制,使得事件具备跨域(跨越两种观察者类型)通知。
模式的扩展
在 Java 中,通过 java.util.Observable 类和 java.util.Observer 接口定义了观察者模式,只要实现它们的子类就可以编写观察者模式实例。
1. Observable类
Observable 类是抽象目标类,它有一个 Vector 向量,用于保存所有要通知的观察者对象,下面来介绍它最重要的 3 个方法。
- void addObserver(Observer o) 方法:用于将新的观察者对象添加到向量中。
- void notifyObservers(Object arg) 方法:调用向量中的所有观察者对象的 update() 方法,通知它们数据发生改变。通常越晚加入向量的观察者越先得到通知。
- void setChange() 方法:用来设置一个 boolean 类型的内部标志位,注明目标对象发生了变化。当它为真时,notifyObservers() 才会通知观察者。
2. Observer 接口
Observer 接口是抽象观察者,它监视目标对象的变化,当目标对象发生变化时,观察者得到通知,并调用 void update(Observable o,Object arg) 方法,进行相应的工作。
【例3】利用 Observable 类和 Observer 接口实现原油期货的观察者模式实例。
分析:当原油价格上涨时,空方伤心,多方局兴;当油价下跌时,空方局兴,多方伤心。本实例中的抽象目标(Observable)类在 Java 中已经定义,可以直接定义其子类,即原油期货(OilFutures)类,它是具体目标类,该类中定义一个 SetPriCe(float price) 方法,当原油数据发生变化时调用其父类的 notifyObservers(Object arg) 方法来通知所有观察者;另外,本实例中的抽象观察者接口(Observer)在 Java 中已经定义,只要定义其子类,即具体观察者类(包括多方类 Bull 和空方类 Bear),并实现 update(Observable o,Object arg) 方法即可。图 5 所示是其结构图。

package net.biancheng.c.observer;import java.util.Observer;import java.util.Observable;public class CrudeOilFutures {public static void main(String[] args) {OilFutures oil = new OilFutures();Observer bull = new Bull(); //多方Observer bear = new Bear(); //空方oil.addObserver(bull);oil.addObserver(bear);oil.setPrice(10);oil.setPrice(-8);}}//具体目标类:原油期货class OilFutures extends Observable {private float price;public float getPrice() {return this.price;}public void setPrice(float price) {super.setChanged(); //设置内部标志位,注明数据发生变化super.notifyObservers(price); //通知观察者价格改变了this.price = price;}}//具体观察者类:多方class Bull implements Observer {public void update(Observable o, Object arg) {Float price = ((Float) arg).floatValue();if (price > 0) {System.out.println("油价上涨" + price + "元,多方高兴了!");} else {System.out.println("油价下跌" + (-price) + "元,多方伤心了!");}}}//具体观察者类:空方class Bear implements Observer {public void update(Observable o, Object arg) {Float price = ((Float) arg).floatValue();if (price > 0) {System.out.println("油价上涨" + price + "元,空方伤心了!");} else {System.out.println("油价下跌" + (-price) + "元,空方高兴了!");}}}油价上涨10.0元,空方伤心了!油价上涨10.0元,多方高兴了!油价下跌8.0元,空方高兴了!油价下跌8.0元,多方伤心了!
7.中介者模式
在现实生活中,常常会出现好多对象之间存在复杂的交互关系,这种交互关系常常是“网状结构”,它要求每个对象都必须知道它需要交互的对象。例如,每个人必须记住他(她)所有朋友的电话;而且,朋友中如果有人的电话修改了,他(她)必须让其他所有的朋友一起修改,这叫作“牵一发而动全身”,非常复杂。
如果把这种“网状结构”改为“星形结构”的话,将大大降低它们之间的“耦合性”,这时只要找一个“中介者”就可以了。如前面所说的“每个人必须记住所有朋友电话”的问题,只要在网上建立一个每个朋友都可以访问的“通信录”就解决了。这样的例子还有很多,例如,你刚刚参加工作想租房,可以找“房屋中介”;或者,自己刚刚到一个陌生城市找工作,可以找“人才交流中心”帮忙。
在软件的开发过程中,这样的例子也很多,例如,在 MVC 框架中,控制器(C)就是模型(M)和视图(V)的中介者;还有大家常用的 QQ 聊天程序的“中介者”是 QQ 服务器。所有这些,都可以采用“中介者模式”来实现,它将大大降低对象之间的耦合性,提高系统的灵活性。
模式的定义与特点
中介者(Mediator)模式的定义:定义一个中介对象来封装一系列对象之间的交互,使原有对象之间的耦合松散,且可以独立地改变它们之间的交互。中介者模式又叫调停模式,它是迪米特法则的典型应用。
说白了,就是通过中介进行注册和转发,双向改变,将对象间的一对多关联转变为一对一的关联
它强调的是同事类之间的交互
中介者模式是一种对象行为型模式,其主要优点如下。
- 类之间各司其职,符合迪米特法则。
- 降低了对象之间的耦合性,使得对象易于独立地被复用。
- 将对象间的一对多关联转变为一对一的关联,提高系统的灵活性,使得系统易于维护和扩展。
其主要缺点是:中介者模式将原本多个对象直接的相互依赖变成了中介者和多个同事类的依赖关系。当同事类越多时,中介者就会越臃肿,变得复杂且难以维护。
模式的结构与实现
1. 模式的结构
中介者模式包含以下主要角色。
- 抽象中介者(Mediator)角色:它是中介者的接口,提供了同事对象注册与转发同事对象信息的抽象方法。
- 具体中介者(Concrete Mediator)角色:实现中介者接口,定义一个 List 来管理同事对象,协调各个同事角色之间的交互关系,因此它依赖于同事角色。
- 抽象同事类(Colleague)角色:定义同事类的接口,保存中介者对象,提供同事对象交互的抽象方法,实现所有相互影响的同事类的公共功能。
- 具体同事类(Concrete Colleague)角色:是抽象同事类的实现者,当需要与其他同事对象交互时,由中介者对象负责后续的交互。
2. 模式的实现
中介者模式的实现代码如下: ```java package net.biancheng.c.mediator; import java.util.*; public class MediatorPattern { public static void main(String[] args) {
} } //抽象中介者 abstract class Mediator { public abstract void register(Colleague colleague); public abstract void relay(Colleague cl); //转发 } //具体中介者 class ConcreteMediator extends Mediator { private ListMediator md = new ConcreteMediator();Colleague c1, c2;c1 = new ConcreteColleague1();c2 = new ConcreteColleague2();md.register(c1);md.register(c2);c1.send();System.out.println("-------------");c2.send();
colleagues = new ArrayList (); public void register(Colleague colleague) {
} public void relay(Colleague cl) {if (!colleagues.contains(colleague)) {colleagues.add(colleague);colleague.setMedium(this);}
} } //抽象同事类 abstract class Colleague { protected Mediator mediator; public void setMedium(Mediator mediator) {for (Colleague ob : colleagues) {if (!ob.equals(cl)) {((Colleague) ob).receive();}}
} public abstract void receive(); public abstract void send(); } //具体同事类 class ConcreteColleague1 extends Colleague { public void receive() {this.mediator = mediator;
} public void send() {System.out.println("具体同事类1收到请求。");
} } //具体同事类 class ConcreteColleague2 extends Colleague { public void receive() {System.out.println("具体同事类1发出请求。");mediator.relay(this); //请中介者转发
} public void send() {System.out.println("具体同事类2收到请求。");
} }System.out.println("具体同事类2发出请求。");mediator.relay(this); //请中介者转发
具体同事类1发出请求。
具体同事类2收到请求。
具体同事类2发出请求。 具体同事类1收到请求。
<a name="QqEIB"></a>## 模式的扩展在实际开发中,通常采用以下两种方法来简化中介者模式,使开发变得更简单。1. 不定义中介者接口,把具体中介者对象实现成为单例。1. 同事对象不持有中介者,而是在需要的时候直接获取中介者对象并调用。```javapackage net.biancheng.c.mediator;import java.util.*;public class SimpleMediatorPattern {public static void main(String[] args) {SimpleColleague c1, c2;c1 = new SimpleConcreteColleague1();c2 = new SimpleConcreteColleague2();c1.send();System.out.println("-----------------");c2.send();}}//简单单例中介者class SimpleMediator {private static SimpleMediator smd = new SimpleMediator();private List<SimpleColleague> colleagues = new ArrayList<SimpleColleague>();private SimpleMediator() {}public static SimpleMediator getMedium() {return (smd);}public void register(SimpleColleague colleague) {if (!colleagues.contains(colleague)) {colleagues.add(colleague);}}public void relay(SimpleColleague scl) {for (SimpleColleague ob : colleagues) {if (!ob.equals(scl)) {((SimpleColleague) ob).receive();}}}}//抽象同事类interface SimpleColleague {void receive();void send();}//具体同事类class SimpleConcreteColleague1 implements SimpleColleague {SimpleConcreteColleague1() {SimpleMediator smd = SimpleMediator.getMedium();smd.register(this);}public void receive() {System.out.println("具体同事类1:收到请求。");}public void send() {SimpleMediator smd = SimpleMediator.getMedium();System.out.println("具体同事类1:发出请求...");smd.relay(this); //请中介者转发}}//具体同事类class SimpleConcreteColleague2 implements SimpleColleague {SimpleConcreteColleague2() {SimpleMediator smd = SimpleMediator.getMedium();smd.register(this);}public void receive() {System.out.println("具体同事类2:收到请求。");}public void send() {SimpleMediator smd = SimpleMediator.getMedium();System.out.println("具体同事类2:发出请求...");smd.relay(this); //请中介者转发}}输出为具体同事类1:发出请求...具体同事类2:收到请求。-----------------具体同事类2:发出请求...具体同事类1:收到请求。
8.迭代器模式
迭代器模式在生活中应用的比较广泛,比如:物流系统中的传送带,不管传送的是什么物品,都会被打包成一个个箱子,并且有一个统一的二维码。这样我们不需要关心箱子里是什么,在分发时只需要一个个检查发送的目的地即可。再比如,我们平时乘坐交通工具,都是统一刷卡或者刷脸进站,而不需要关心是男性还是女性、是残疾人还是正常人等信息。
迭代器(Iterator)模式的定义:提供一个对象来顺序访问聚合对象中的一系列数据,而不暴露聚合对象的内部表示。
也就是说,把东西都放到箱子里面, 你看不到箱子里的东西, 箱子按照一定的顺序排列执行, 这便是迭代器的思想
基本上每个语言都有自己的迭代器,迭代器内部是一个List
