Java——设计模式（行为型模式）
1、责任链模式
2、命令模式
在软件开发中，咱们常常须要向某些对象发送请求(调用其中的某个或某些方法)，可是并不知道请求的接收者是谁，也不知道被请求的操做是哪一个，此时，咱们特别但愿可以以一种松耦合的方式来设计软件，使得请求发送者与请求接收者可以消除彼此之间的耦合，让对象之间的调用关系更加灵活，能够灵活地指定请求接收者以及被请求的操做。命令模式为此类问题提供了一个较为完美的解决方案。命令模式能够将请求发送者和接收者彻底解耦，发送者与接收者之间没有直接引用关系，发送请求的对象只须要知道如何发送请求，而没必要知道如何完成请求。命令模式定义以下:java
命令模式(Command Pattern):将一个请求封装为一个对象，从而让咱们可用不一样的请求对客户进行参数化;对请求排队或者记录请求日志，以及支持可撤销的操做。命令模式是一种对象行为型模式，其别名为动做(Action)模式或事务(Transaction)模式。算法
命令模式的定义比较复杂，提到了不少术语，例如“用不一样的请求对客户进行参数化”、“对请求排队”、“记录请求日志”、“支持可撤销操做”等，在后面咱们将对这些术语进行一一讲解。编程
命令模式的核心在于引入了命令类，经过命令类来下降发送者和接收者的耦合度，请求发送者只需指定一个命令对象，再经过命令对象来调用请求接收者的处理方法，其结构如图所示:设计模式
Command(抽象命令类):抽象命令类通常是一个抽象类或接口，在其中声明了用于执行请求的 execut e() 等方法，经过这些方法能够调用请求接收者的相关操做。学习
ConcreteCommand(具体命令类):具体命令类是抽象命令类的子类，实现了在抽象命令类中声明的方 法，它对应具体的接收者对象，将接收者对象的动做绑定其中。在实现 execute() 方法时，将调用接收者对 象的相关操做(Action)。ui
Invoker(调用者):调用者即请求发送者，它经过命令对象来执行请求。一个调用者并不须要在设计时肯定 其接收者，所以它只与抽象命令类之间存在关联关系。在程序运行时能够将一个具体命令对象注入其中，再 调用具体命令对象的 execute() 方法，从而实现间接调用请求接收者的相关操做。this
Receiver(接收者):接收者执行与请求相关的操做，它具体实现对请求的业务处理。spa
命令模式的本质是对请求进行封装，一个请求对应于一个命令，将发出命令的责任和执行命令的责任分割开。每 一个命令都是一个操做:请求的一方发出请求要求执行一个操做;接收的一方收到请求，并执行相应的操做。命令模式容许请求的一方和接收的一方独立开来，使得请求的一方没必要知道接收请求的一方的接口，更没必要知道请求如何被接收、操做是否被执行、什么时候被执行，以及是怎么被执行的。设计
命令模式的关键在于引入了抽象命令类，请求发送者针对抽象命令类编程，只有实现了抽象命令类的具体命令才 与请求接收者相关联。在最简单的抽象命令类中只包含了一个抽象的execute() 方法，每一个具体命令类将一个Receiver 类型的对象做为一个实例变量进行存储，从而具体指定一个请求的接收者，不一样的具体命令类提供了 execute() 方法的不一样实现，并调用不一样接收者的请求处理方法。 日志
public class A {
//功能键设置窗口类
class FBSettingWindow {
private String title; //窗口标题
//定义一个ArrayList来存储全部功能键
private ArrayList<FunctionButton> functionButtons = new ArrayList<FunctionButton>();
public void addFunctionButton(FunctionButton fb) {
functionButtons.add(fb);
}
public void removeFunctionButton(FunctionButton fb) {
functionButtons.remove(fb);
}
//显示窗口及功能键
public void display() {
System.out.println("显示窗口:" + this.title);
System.out.println("显示功能键:");
for (Object obj : functionButtons) {
System.out.println(((FunctionButton) obj).getName());
}
System.out.println("------------------------------");
}
}
//功能键类:请求发送者
class FunctionButton {
private String name; //功能键名称
private Command command; //维持一个抽象命令对象的引用
public FunctionButton(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
//为功能键注入命令
public void setCommand(Command command) {
this.command = command;
}
//发送请求的方法
public void onClick() {
System.out.print("点击功能键:");
command.execute();
}
}
//抽象命令类
abstract class Command {
public abstract void execute();
}
//帮助命令类:具体命令类
class HelpCommand extends Command {
private HelpHandler hhObj; //维持对请求接收者的引用
public HelpCommand() {
hhObj = new HelpHandler();
}
//命令执行方法，将调用请求接收者的业务方法
public void execute() {
hhObj.display();
}
}
//最小化命令类:具体命令类
class MinimizeCommand extends Command {
private WindowHanlder whObj; //维持对请求接收者的引用
public MinimizeCommand() {
whObj = new WindowHanlder();
}
//命令执行方法，将调用请求接收者的业务方法
public void execute() {
whObj.minimize();
}
}
//窗口处理类:请求接收者
class WindowHanlder {
public void minimize() {
System.out.println("将窗口最小化至托盘!");
}
}
//帮助文档处理类:请求接收者
class HelpHandler {
public void display() {
System.out.println("显示帮助文档!");
}
}
}
// 客户端调用
class Client {
public static void main(String args[]) {
FBSettingWindow fbsw = new FBSettingWindow("功能键设置");
FunctionButton fb1, fb2;
fb1 = new FunctionButton("功能键1");
fb2 = new FunctionButton("功能键1");
Command command1, command2; //经过读取配置文件和反射生成具体命令对象
command1 = (Command) XMLUtil.getBean(0);
command2 = (Command) XMLUtil.getBean(1);
//将命令对象注入功能键
fb1.setCommand(command1);
fb2.setCommand(command2);
fbsw.addFunctionButton(fb1);
fbsw.addFunctionButton(fb2);
fbsw.display();
//调用功能键的业务方法
fb1.onClick();
fb2.onClick();
}
}
若是须要修改功能键的功能，例如某个功能键能够实现“自动截屏”，只须要对应增长一个新的具体命令类，在该命令类与屏幕处理者(ScreenHandler)之间建立一个关联关系，而后将该具体命令类的对象经过配置文件注 入到某个功能键便可，原有代码无须修改，符合“开闭原则”。在此过程当中，每个具体命令类对应一个请求的 处理者(接收者)，经过向请求发送者注入不一样的具体命令对象可使得相同的发送者对应不一样的接收者，从而 实现“将一个请求封装为一个对象，用不一样的请求对客户进行参数化”，客户端只须要将具体命令对象做为参数 注入请求发送者，无须直接操做请求的接收者。
优势（我以为咱们确定用不上）
(1) 下降系统的耦合度。因为请求者与接收者之间不存在直接引用，所以请求者与接收者之间实现彻底解耦，相同 的请求者能够对应不一样的接收者，一样，相同的接收者也能够供不一样的请求者使用，二者之间具备良好的独立 性。
(2) 新的命令能够很容易地加入到系统中。因为增长新的具体命令类不会影响到其余类，所以增长新的具体命令类 很容易，无须修改原有系统源代码，甚至客户类代码，知足“开闭原则”的要求。
(3) 能够比较容易地设计一个命令队列或宏命令(组合命令)。
(4) 为请求的撤销(Undo)和恢复(Redo)操做提供了一种设计和实现方案。
缺点
使用命令模式可能会致使某些系统有过多的具体命令类。由于针对每个对请求接收者的调用操做都须要设计一 个具体命令类，所以在某些系统中可能须要提供大量的具体命令类，这将影响命令模式的使用。
适用场景
(1) 系统须要将请求调用者和请求接收者解耦，使得调用者和接收者不直接交互。请求调用者无须知道接收者的存在，也无须知道接收者是谁，接收者也无须关心什么时候被调用。
(2) 系统须要在不一样的时间指定请求、将请求排队和执行请求。一个命令对象和请求的初始调用者能够有不一样的生 命期，换言之，最初的请求发出者可能已经不在了，而命令对象自己仍然是活动的，能够经过该命令对象去调用 请求接收者，而无须关心请求调用者的存在性，能够经过请求日志文件等机制来具体实现。
(3) 系统须要支持命令的撤销(Undo)操做和恢复(Redo)操做。
(4) 系统须要将一组操做组合在一块儿造成宏命令。
3、迭代器模式
迭代器模式(Iterator Pattern):提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。
public class A {
interface Iterator {
void first(); //将游标指向第一个元素
void next(); //将游标指向下一个元素
boolean hasNext(); //判断是否存在下一个元素
Object currentItem(); //获取游标指向的当前元素
}
class ConcreteIterator implements Iterator {
private ConcreteAggregate objects; //维持一个对具体聚合对象的引用，以便于访问存储在聚合对象中的数据
private int cursor; //定义一个游标，用于记录当前访问位置
public ConcreteIterator(ConcreteAggregate objects) {
this.objects = objects;
}
public void first() { ......}
public void next() { ......}
public boolean hasNext() { ......}
public Object currentItem() { ......}
}
// 聚合类
interface Aggregate {
Iterator createIterator();
}
// 具体聚合类是抽象聚合类的子类，一方面负责存储数据，
// 另外一方面实现了在抽象聚合类中声明的工厂方法 createIterator()，用于返回一个与该具体聚合类对应的具体迭代器对象
class ConcreteAggregate implements Aggregate {
......
public Iterator createIterator() {
return new ConcreteIterator(this);
}
......
}
}
优势
(1) 它支持以不一样的方式遍历一个聚合对象，在同一个聚合对象上能够定义多种遍历方式。在迭代器模式中只须要用一个不一样的迭代器来替换原有迭代器便可改变遍历算法，咱们也能够本身定义迭代器的子类以支持新的遍历方式。
(2) 迭代器简化了聚合类。因为引入了迭代器，在原有的聚合对象中不须要再自行提供数据遍历等方法，这样能够简化聚合类的设计。
(3) 在迭代器模式中，因为引入了抽象层，增长新的聚合类和迭代器类都很方便，无须修改原有代码，知足“开闭原则”的要求。
缺点
(1) 因为迭代器模式将存储数据和遍历数据的职责分离，增长新的聚合类须要对应增长新的迭代器类，类的个数成 对增长，这在必定程度上增长了系统的复杂性。
(2) 抽象迭代器的设计难度较大，须要充分考虑到系统未来的扩展，例如 JDK 内置迭代器 Iterator 就没法实现逆向遍历，若是须要实现逆向遍历，只能经过其子类 ListIterator 等来实现，而 ListIterator 迭代器没法用于操做 Set 类型的聚合对象。在自定义迭代器时，建立一个考虑全面的抽象迭代器并非件很容易的事情。
适用场景
(1) 访问一个聚合对象的内容而无须暴露它的内部表示。将聚合对象的访问与内部数据的存储分离，使得访问聚合 对象时无须了解其内部实现细节。
(2) 须要为一个聚合对象提供多种遍历方式。
(3) 为遍历不一样的聚合结构提供一个统一的接口，在该接口的实现类中为不一样的聚合结构提供不一样的遍历方式，而客户端能够一致性地操做该接口。
4、观察者模式（对象间的联动）
观察者模式是使用频率最高的设计模式之一，它用于创建一种对象与对象之间的依赖关系，一个对象发生改变时将自动通知其余对象，其余对象将相应做出反应。在观察者模式中，发生改变的对象称为观察目标，而被通知的对象称为观察者，一个观察目标能够对应多个观察者，并且这些观察者之间能够没有任何相互联系，能够根据须要增长和删除观察者，使得系统更易于扩展。
观察者模式定义以下:
观察者模式(Observer Pattern):定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆获得通知并被自动更新。观察者模式的别名包括发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式或从属者(Dependents)模 式。观察者模式是一种对象行为型模式。
观察者模式结构中一般包括观察目标和观察者两个继承层次结构，其结构如图所示:
- Subject(目标):目标又称为主题，它是指被观察的对象。在目标中定义了一个观察者集合，一个观察目标能够接受任意数量的观察者来观察，它提供一系列方法来增长和删除观察者对象，同时它定义了通知方法 notify()。目标类能够是接口，也能够是抽象类或具体类。
- ConcreteSubject(具体目标):具体目标是目标类的子类，一般它包含有常常发生改变的数据，当它的状态发生改变时，向它的各个观察者发出通知;同时它还实现了在目标类中定义的抽象业务逻辑方法(若是有的话)。若是无须扩展目标类，则具体目标类能够省略。
- Observer(观察者):观察者将对观察目标的改变作出反应，观察者通常定义为接口，该接口声明了更新数据的方法update()，所以又称为抽象观察者。
- ConcreteObserver(具体观察者):在具体观察者中维护一个指向具体目标对象的引用，它存储具体观察 者的有关状态，这些状态须要和具体目标的状态保持一致;它实现了在抽象观察者 Observer 中定义的 update() 方法。一般在实现时，能够调用具体目标类的 attach() 方法将本身添加到目标类的集合中或经过 detach() 方法将本身从目标类的集合中删除。
观察者模式描述了如何创建对象与对象之间的依赖关系，以及如何构造知足这种需求的系统。
观察者模式与责任链模式都是在内部存的对象的引用，经过调用方法的方式达到通知的目的，可是责任链是链式调用，一次只能通知一个观察者。
public class A {
//抽象观察类
interface Observer {
public String getName();
public void setName(String name);
public void help(); //声明支援盟友方法
public void beAttacked(AllyControlCenter acc); //声明遭受攻击方法
}
//战队成员类:具体观察者类
class Player implements Observer {
private String name;
public Player(String name) {
this.name = name;
}
public void setName(String name) {
this.name = name;
}
public String getName() {
return this.name;
}
//支援盟友方法的实现
public void help() {
System.out.println("坚持住，" + this.name + "来救你!");
}
//遭受攻击方法的实现，当遭受攻击时将调用战队控制中心类的通知方法notifyObserver()来通知盟友
public void beAttacked(AllyControlCenter acc) {
System.out.println(this.name + "被攻击!");
acc.notifyObserver(name);
}
}
//战队控制中心类:目标类
abstract class AllyControlCenter {
protected String allyName; //战队名称
protected ArrayList<Observer> players = new ArrayList<Observer>(); //定义一个集合用于存储战队成员
public void setAllyName(String allyName) {
this.allyName = allyName;
}
public String getAllyName() {
return this.allyName;
}
//注册方法
public void join(Observer obs) {
System.out.println(obs.getName() + "加入" + this.allyName + "战队!");
players.add(obs);
}
//注销方法
public void quit(Observer obs) {
System.out.println(obs.getName() + "退出" + this.allyName + "战队!");
players.remove(obs);
}
//声明抽象通知方法
public abstract void notifyObserver(String name);
}
//具体战队控制中心类:具体目标类
class ConcreteAllyControlCenter extends AllyControlCenter {
public ConcreteAllyControlCenter(String allyName) {
System.out.println(allyName + "战队组建成功!");
System.out.println("----------------------------");
this.allyName = allyName;
}
//实现通知方法
public void notifyObserver(String name) {
System.out.println(this.allyName + "战队紧急通知，盟友" + name + "遭受敌人攻击!"); //遍历观察者集合，调用每个盟友(本身除外)的支援方法
for (Observer obs : players) {
if (!obs.getName().equalsIgnoreCase(name)) {
obs.help();
}
}
}
}
}
客户端类
class Client {
public static void main(String args[]) {
//定义观察目标对象
AllyControlCenter acc = new ConcreteAllyControlCenter("金庸群侠");
//定义四个观察者对象
Observer player1, player2, player3, player4;
player1 = new Player("杨过");
acc.join(player1);
player2 = new Player("令狐冲");
acc.join(player2);
player3 = new Player("张无忌");
acc.join(player3);
player4 = new Player("段誉");
acc.join(player4);
//某成员遭受攻击（通知其它成员）
player1.beAttacked(acc);
}
}
JDK 对观察者模式的支持
观察者模式在 Java 语言中的地位很是重要。在 JDK 的 java.util 包中，提供了 Observable 类以及 Observer 接口，它们构成了 JDK 对观察者模式的支持。
优势
(1) 观察者模式能够实现表示层和数据逻辑层的分离，定义了稳定的消息更新传递机制，并抽象了更新接口，使得能够有各类各样不一样的表示层充当具体观察者角色。
(2) 观察者模式在观察目标和观察者之间创建一个抽象的耦合。观察目标只须要维持一个抽象观察者的集合，无须 了解其具体观察者。因为观察目标和观察者没有紧密地耦合在一块儿，所以它们能够属于不一样的抽象化层次。
(3) 观察者模式支持广播通讯，观察目标会向全部已注册的观察者对象发送通知，简化了一对多系统设计的难度。
(4) 观察者模式知足“开闭原则”的要求，增长新的具体观察者无须修改原有系统代码，在具体观察者与观察目标 之间不存在关联关系的状况下，增长新的观察目标也很方便。
缺点
(1) 若是一个观察目标对象有不少直接和间接观察者，将全部的观察者都通知到会花费不少时间。
(2) 若是在观察者和观察目标之间存在循环依赖，观察目标会触发它们之间进行循环调用，可能致使系统崩溃。
(3) 观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生 了变化。
适用场景
(1) 一个抽象模型有两个方面，其中一个方面依赖于另外一个方面，将这两个方面封装在独立的对象中使它们能够各 自独立地改变和复用。
(2) 一个对象的改变将致使一个或多个其余对象也发生改变，而并不知道具体有多少对象将发生改变，也不知道这 些对象是谁。
(3) 须要在系统中建立一个触发链，A 对象的行为将影响B对象，B 对象的行为将影响 C 对象......，可使用观察者模式建立一种链式触发机制。
观察者模式与责任链模式区别
在底层的实现上差很少，观察者模式内部存的是一个List<Observer>，责任链模式内部存的是this对象的引用
观察者模式是为了解决对象间的一种一对多依赖关系，使得每当一个对象改变状态，则其相关依赖对象皆获得通知并被自动更新。（不必定是同一个东西，只是一个触发器）
责任链模式是为了解决多个处理耦合在一块儿（为了单一原则），从而拆分红多个类进行处理（处理同一个东西）
学习设计模式有什么用
设计模式是围绕着那6大原则设计的，最主要的是“开闭原则”，为了方便大型系统的扩展，学习设计模式的时候必定要了解这些设计模式的存在是为了解决什么问题的。
- 1. [Java] [设计模式] [行为型模式] [模板方法模式]
- 2. 设计模式：行为型模式（2）
- 3. 【设计模式】行为型模式（上）
- 4. 设计模式——行为型模式（一）
- 5. 设计模式之行为型模式
- 6. 【设计模式】行为型模式
- 7. 设计模式——行为型模式
- 8. 设计模式-行为型模式
- 9. 【设计模式】行为型模式（下）
- 10. 设计模式— 行为型模式
- 更多相关文章...
- • Scala 模式匹配 - Scala教程
- • SVN 启动模式 - SVN 教程
- • 委托模式
- • IntelliJ IDEA代码格式化设置
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. [Java] [设计模式] [行为型模式] [模板方法模式]
- 2. 设计模式：行为型模式（2）
- 3. 【设计模式】行为型模式（上）
- 4. 设计模式——行为型模式（一）
- 5. 设计模式之行为型模式
- 6. 【设计模式】行为型模式
- 7. 设计模式——行为型模式
- 8. 设计模式-行为型模式
- 9. 【设计模式】行为型模式（下）
- 10. 设计模式— 行为型模式