共计 9678 个字符，预计需要花费 25 分钟才能阅读完成。
如同每天一种模式节奏有点太慢，内容也有点少，所以还是试试每篇 3 – 4 种模式，而后 2 天一更叭。
首先，罕用的设计模式分为 3 大类，创立型模式、行为型模式和结构型模式。前两篇所写的工厂模式和建造者模式就是属于创立型模式的内容。
责任链模式
责任链模式能够拆分为责任和链，责任是指有责任去干嘛，链能够参考链表嘛，有下一级。
场景：当初你是某公司的员工，拿到了一个比拟紧急的文件（文件的紧急性必定不一样嘛），须要更高一层的领导来解决下文件。
一般模式
文件类：
public class File {
private FileClass fileClass; // 文件的重要等级
private String content; // 文件的内容
// 省略
}
// 枚举类示意文件的重要等级
enum FileClass {
NORMAL,
IMPORTANT,
EMERGENCY
}员工接口：
public interface IStaff {
// 获取员工的名字
public String getName();
// 获取要解决文件的等级
public FileClass getFileClass();
// 获取员工的需要
public String getRequest();}员工：
public class Staff implements IStaff {
private File file;
private String name;
// 省略构造函数
@Override
public String getName() {return name;}
@Override
public FileClass getFileClass() {return file.getFileClass();
}
@Override
public String getRequest() {return "这份文件【" + file.getContent() +"】须要解决下";
}
}领导接口：
public interface IHandler {
// 解决文件
public void handle(IStaff staff);
}组长：
public class Leader implements IHandler {
@Override
public void handle(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println("组长：当初解决");
}
}总监：
public class Director implements IHandler{
@Override
public void handle(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println("总监：当初解决");
}
}主管：
public class Supervisor implements IHandler {
@Override
public void handle(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println("主管：当初解决");
}
}Client：
public class Client {public static void main(String[] args) {File file = new File(FileClass.IMPORTANT, "策动计划");
IStaff staff = new Staff(file, "imperfect");
if(file.getFileClass().equals(FileClass.NORMAL)) {new Leader().handle(staff);
} else if(file.getFileClass().equals(FileClass.IMPORTANT)) {new Director().handle(staff);
} else if(file.getFileClass().equals(FileClass.EMERGENCY)) {new Supervisor().handle(staff);
} else {System.out.println("权限不够");
}
}
}你瞅瞅，认真品，这一堆 if else 间接在 Client 类给裸露进去了，而且是在 Client 中才进行判断不同等级给不同的领导解决。
艰深地比喻呢，就是员工拿到了文件后，把本人的组长，总监，主管全都叫到本人跟前，而后说，这份文件是比拟重要的，给你们谁解决才有权限。的确是能够实现人物，然而这样的形式事实吗？
靠近事实的一种形式是怎么样的呢，员工拿到文件后，首先给本人的间接领导组长，在领导层（handler）中的最低的一层（链头 ）。接着组长再看本人有没有 责任 去解决文件，没有的话再给下一层来解决，这就是 责任链模式。
责任链模式
文件类和员工类不变，次要是领导层（handler）的变动。
形象领导类：
public abstract class AbstractHandler {
private FileClass fileClass;
private AbstractHandler nextHandler;
private String name;
// 在类结构的时候就明确了职责
// 就像你入职就晓得本人的责任是解决什么文件
public AbstractHandler(FileClass fileClass, String name) {
this.fileClass = fileClass;
this.name = name;
}
// 获得领导的名字
public String getName() {return name;}
// 没有责任，交给下一级
public void setNextHandler(AbstractHandler nextHandler) {this.nextHandler = nextHandler;}
// 解决回应，每个人的回应形式不一样，所以形象进去
public abstract void respond(IStaff staff);
// 解决信息
public void handle(IStaff staff) {if(fileClass.equals(staff.getFileClass())) {respond(staff);
} else {if(nextHandler != null) {nextHandler.respond(staff);
} else {System.out.println("曾经到最高权限！！！");
}
}
}
}组长：
public class Leader extends AbstractHandler {public Leader(String name) {super(FileClass.NORMAL, name);
}
@Override
public void respond(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println(getName() + "组长：做出了回应");
}
}总监：
public class Director extends AbstractHandler{public Director(String name) {super(FileClass.IMPORTANT, name);
}
@Override
public void respond(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println(getName() + "总监：做出了回应");
}
}主管：
public class Supervisor extends AbstractHandler {public Supervisor(String name) {super(FileClass.EMERGENCY, name);
}
@Override
public void respond(IStaff staff) {System.out.println(staff.getName() + ":" + staff.getRequest());
System.out.println(getName() + "主管：做出了回应");
}
}Client：
public class Client {public static void main(String[] args) {File file = new File(FileClass.IMPORTANT, "营销计划");
IStaff staff = new Staff(file, "imperfect");
// 创立领导层
AbstractHandler leader = new Leader("leaderWu");
AbstractHandler director = new Director("directorWu");
AbstractHandler supervisor = new Supervisor("supervisorWu");
// 设置层级关系，跟链表相似
leader.setNextHandler(director);
director.setNextHandler(supervisor);
// 首先交给间接领导解决
leader.handle(staff);
}
}优缺点
- 长处：解决和申请离开，员工不晓得最终文件是谁解决的
- 毛病：毛病也非常显著，如果责任链很长，而解决者刚好在最初，是不是要遍历完责任链。这样性能就比拟低，在理论应用中，个别会折这一个最大链长来保障性能。
UML 类图
命令模式
命令模式，一句话就是给你一个命令，必须要恪守并且执行，有点像是军队外面“服从命令是军人的天职”。
不晓得大学有没有加入过数学建模，反正我是没有加入过，然而有理解过个别形成，一个小队外面个别有次要负责 搜寻的同学，写代码的同学，写论文的同学和指导老师
一般模式
形象成员类(receiver)：
public abstract class NTeammate {public abstract void changeRequire();
public abstract void modify();
public abstract void work();}Searcher:
public class NSearcher extends NTeammate {
@Override
public void changeRequire() {System.out.println("searcher 理解到需要扭转");
}
@Override
public void modify() {}
@Override
public void work() {System.out.println("searcher 开始搜寻相干信息");
}
}Writer:
public class NWriter extends NTeammate {
@Override
public void changeRequire() {System.out.println("writer 理解到需要扭转");
}
@Override
public void modify() {System.out.println("writer 批改论文");
}
@Override
public void work() {System.out.println("writer 开始写论文");
}
}Coder:
public class NCoder extends NTeammate {
@Override
public void changeRequire() {System.out.println("coder 理解到需要扭转");
}
@Override
public void modify() {System.out.println("coder 批改代码");
}
@Override
public void work() {System.out.println("coder 开始码代码");
}
}Teacher:
public class NTeacher {public static void main(String[] args) {NTeammate writer = new NWriter();
// 须要改文章了
writer.modify();
writer.work();}
} 一开始，老师看到写的文展不够简洁，所以就打电话给 writer，让他批改，所以就有了下面的 Teacher 类。这样其实还好，因为文章嘛，批改润色就好了。
过了一天，老师认真看了下后，发现代码的算法有 bug，这个破绽导致了不仅 coder 要批改代码，writer 也要批改相应中央的文章。
老师这下不仅要分割 writer，也得分割 coder，那么 Teacher 类应该怎么批改呢？
public class NTeacher {public static void main(String[] args) {NTeammate writer = new NWriter();
NTeammate coder = new NCoder();
// 须要改 bug 和文章了
writer.modify();
writer.work();
coder.modify();
coder.work();}
} 能够发现，就多了一个需要，代码较之前曾经有很大的改变了，这是咱们不心愿看到的。可能有的小伙伴会想到利用中介者模式，不过中介者模式是为了减小类和类之间的耦合，这个例子中的 searcher，writer，coder 并没有耦合，都在各司其职。
命令模式
如果小队外面有个队长（Invoker）就好了，能够和老师（client）沟通，不止这样，老师的指令实现起来必定是 String 类型，咱们能够把指令封装称一个类（command），队长只须要发布命令，命令批示队员（receiver）来做什么。这就是命令模式，队员必须执行命令要求做的。
形象队员以及具体队员还是和下面一样，这里就不再赘述。
形象命令类：
public abstract class AbstractCommand {protected Coder coder = new Coder();
protected Searcher searcher = new Searcher();
protected Writer writer = new Writer();
// 肯定要有个执行的办法，下达一个命令
public abstract void execute();}具体命令类(Command)：
有哪些命令，都能够封装起来
扭转需要：
public class ChangeInfoCommand extends AbstractCommand {
@Override
public void execute() {searcher.changeRequire();
writer.changeRequire();
coder.changeRequire();}
}修改文章：
public class ModifyArticleCommand extends AbstractCommand {
@Override
public void execute() {writer.modify();
writer.work();}
}批改代码：
public class ModifyCodeCommand extends AbstractCommand {
@Override
public void execute() {coder.modify();
coder.work();
writer.modify();
writer.work();}
}队长类(Invoke)：
public class Captain {
// 和命令产生分割
AbstractCommand abstractCommand;
public Captain(AbstractCommand abstractCommand) {this.abstractCommand = abstractCommand;}
public void invoke() {
// 发布命令要求队员进行相应的动作
abstractCommand.execute();}
}老师类(Client)：
public class Teacher {public static void main(String[] args) {AbstractCommand command = new ModifyCodeCommand();
Captain captain = new Captain(command);
captain.invoke();}
}如果老师感觉又不好了，这些怎么办呢，没有必要和成员练习，只须要提出另外一个倡议，队长也不要跟队员练习，只须要发布命令，由命令批示队员去做。批改就是这么简略，一行代码的事件。
public class Teacher {public static void main(String[] args) {//AbstractCommand command = new ModifyCodeCommand();
AbstractCommand command = new ModifyArticleCommand();
Captain captain = new Captain(command);
captain.invoke();}
}扩大
如果说，诶，改代码的时候不仅须要批改 bug 和修改文章，也须要 searcher 来收集信息，怎么办呢？
public class ModifyCodeCommand extends AbstractCommand {
@Override
public void execute() {searcher.work(); // 只须要在具体的命令外面增加即可，客户端是齐全不晓得的
coder.modify();
coder.work();
writer.modify();
writer.work();}
}还有一种状况就是，某些批改之后，老师发现还是之前的版本比拟好，这就要求每个队员都有一个回调函数来撤销动作，返回到上一个状态，就是找到保留的之前版本的文件。只须要在形象 receiver 类加一个回调函数即可：
public abstract class NTeammate {public abstract void changeRequire();
public abstract void modify();
public abstract void work();
// 具体队友在依据本人的形式实现回调办法
public abstract void rollback();}接着就是增加一个 撤回命令
public class callBackCommand extends AbstractCommand {
@Override
public void execute() {
// 当然，须要谁撤回是能够扭转的
searcher.rollback();
writer.rollback();
coder.rollback();}
}UML 类图
解释器模式
这个无论是工作上还是学习中都是比拟冷门的设计模式。解释器模式由以下类组成
- Context： Context 用于封装解释器的全局信息，所有具体的解释器均须要拜访 Context。
- AbstractExpression： 一个抽象类或接口，申明执行的解释办法，由所有具体的解释器实现
- TerminalExpression： 一种解释器类，实现与语法的终结符相干的操作。终结符表达式必须终结被实现和实例化，因为它示意表达式的结尾。
- NonTerminalExpreesion： 这是实现语法的不同规定或符号的类。对于每一种语法都应该创立一个类。
这个货色解释起来比拟拗口，一时也没有很好的艰深的解释，那就间接看例子叭。
AbstractExpression
public interface Expression {public float interpret();
}TerminalExpression
public class Number implements Expression{
private final float number;
public Number(float number) {this.number = number;}
@Override
public float interpret() {return number;}
}还记得之前说过的流吗，TerminalExpression 就相似终结操作，而NonTerminalExpression 就是相似两头操作
NonTerminalExpression
public class Plus implements Expression{
Expression left;
Expression right;
public Plus(Expression left, Expression right) {
this.left = left;
this.right = right;
}
@Override
public float interpret() {return left.interpret() + right.interpret();}
}留神对于每一个语法都要有一个独立的类
public class Minus implements Expression {
Expression left;
Expression right;
public Minus(Expression left, Expression right) {
this.left = left;
this.right = right;
}
@Override
public float interpret() {return left.interpret() - right.interpret();}
}Context
public class Evaluator {public static void main(String[] args) {Evaluator evaluator = new Evaluator();
System.out.println(evaluator.evaluate("3 4 +"));
System.out.println(evaluator.evaluate("4 3 -"));
System.out.println(evaluator.evaluate("4 3 - 2 +"));
}
public float evaluate(String expression) {Stack<Expression> stack = new Stack<>();
float result = 0;
for (String token : expression.split(" ")) {
Expression exp = null;
if (isOperator(token)) {if (token.equals("+")) {exp = stack.push(new Plus(stack.pop(), stack.pop()));
} else if (token.equals("-")) {exp = stack.push(new Minus(stack.pop(), stack.pop()));
}
if (null != exp) {result = exp.interpret();
stack.push(new Number(result));
}
}
if (isNumber(token)) {stack.push(new Number(Float.parseFloat(token)));
}
}
return result;
}
private boolean isNumber(String token) {
try {Float.parseFloat(token);
return true;
} catch (NumberFormatException e) {return false;}
}
private boolean isOperator(String token) {return token.equals("+") || token.equals("-");
}
}UML 类图
正文完