创建网站目录时我们应该,吕梁市建设局网站,备案网查询,阿里 网站建设方案书 模板观察者模式 我们可以比喻观察者模式是一种类似广播的设计模式 介绍 观察者模式#xff1a;对象之间多对一依赖的一种设计方案#xff0c;被依赖的对象是Subject#xff0c;依赖的对象是Observer#xff0c;Subject通知Observer变化。 代码 说明#xff1a; WeatherStat…观察者模式 我们可以比喻观察者模式是一种类似广播的设计模式 介绍 观察者模式对象之间多对一依赖的一种设计方案被依赖的对象是Subject依赖的对象是ObserverSubject通知Observer变化。 代码 说明 WeatherStation 充当主题WeatherDisplay 充当观察者。WeatherStation 维护了一个观察者列表提供了注册、移除和通知观察者的方法。当天气更新时调用 updateWeather() 方法来模拟更新天气并通知观察者。观察者收到通知后会调用 update() 方法来更新天气信息。 import java.util.ArrayList; import java.util.List; ​ // 主题接口 interface WeatherSubject {void registerObserver(WeatherObserver observer);void removeObserver(WeatherObserver observer);void notifyObservers(); } ​ // 观察者接口 interface WeatherObserver {void update(String weather); } ​ // 具体主题类 class WeatherStation implements WeatherSubject {private ListWeatherObserver observers new ArrayList();private String weather; ​Overridepublic void registerObserver(WeatherObserver observer) {observers.add(observer);} ​Overridepublic void removeObserver(WeatherObserver observer) {observers.remove(observer);} ​Overridepublic void notifyObservers() {for (WeatherObserver observer : observers) {observer.update(weather);}} ​// 模拟天气更新并通知观察者public void updateWeather(String newWeather) {this.weather newWeather;notifyObservers();} } ​ // 具体观察者类 class WeatherDisplay implements WeatherObserver {private String observerName; ​public WeatherDisplay(String observerName) {this.observerName observerName;} ​Overridepublic void update(String weather) {System.out.println(observerName 收到天气更新: weather);} } ​ public class WeatherObserverExample {public static void main(String[] args) {// 创建天气主题WeatherStation weatherStation new WeatherStation(); ​// 创建天气显示观察者WeatherObserver observer1 new WeatherDisplay(观察者1);WeatherObserver observer2 new WeatherDisplay(观察者2); ​// 注册观察者weatherStation.registerObserver(observer1);weatherStation.registerObserver(observer2); ​// 模拟天气更新weatherStation.updateWeather(晴天); ​// 移除观察者2weatherStation.removeObserver(observer2); ​// 再次模拟天气更新weatherStation.updateWeather(下雨);} } ​ 观察者莫斯在JDK中的使用分析 JDK中的Observable使用了观察者模式。 直接追源码看它的结构 1、addObserver添加 2、deleteObserver删除 3、notifyObserver通知 4、VectorObserver观察者列表 总结 个人理解观察者模式就是一种似广播的模式一个站对多个对象。 观察者模式Observer Pattern是一种软件设计模式它定义了一种一对多的依赖关系使得多个观察者对象同时监听某一个主题对象。当主题对象的状态发生变化时所有依赖于它的观察者都会得到通知并自动更新。 结构 观察者模式通常包含以下角色 Subject主题它是被观察的对象当其状态发生变化时会通知观察者。主题可以是一个接口或抽象类定义了注册、删除和通知观察者的方法。 ConcreteSubject具体主题实现了主题接口或抽象类它存储了一系列观察者对象状态发生变化时会通知这些观察者。 Observer观察者定义了一个更新接口以便主题在状态发生变化时能够通知到它。 ConcreteObserver具体观察者实现了观察者接口它需要注册到具体主题对象中以便在主题状态发生变化时接收通知并进行相应的处理。 工作原理 当主题对象的状态发生变化时会调用主题对象的通知方法。 主题对象的通知方法会遍历注册在其中的所有观察者对象并调用它们的更新方法。 观察者对象在接收到通知后会执行相应的更新操作以使自身状态与主题对象保持同步。 优点 松耦合观察者模式将主题对象和观察者对象之间的耦合度降到了最低主题和观察者之间彼此独立地变化。 扩展性好可以根据需要随时增加新的观察者或主题使系统更易于扩展。 符合开闭原则系统中新增加观察者或主题不需要修改原有的代码。 适用场景 当一个对象的改变需要同时影响其他对象而且不知道具体有多少对象需要被通知时可以考虑使用观察者模式。 当一个抽象模型有两个方面其中一个方面依赖于另一个方面但又需要独立于其变化时可以考虑使用观察者模式。 当一个对象的改变需要同时影响到其他对象而且你不希望知道具体有多少对象需要被通知时可以考虑使用观察者模式。 观察者模式在软件开发中被广泛应用例如 GUI 开发中的事件监听器、Android 中的广播机制等。 中介者模式 可以将中介者模式理解成一种通过中间类来进行通信和协调的设计模式 介绍 1、中介者模式是一种行为型设计模式用来减少对象间的直接耦合 2、在中介者模式中对象之间不再相互通信而是通过一个中介者对象来进行通信。这有助于降低系统的复杂度提高系统的可维护性和可扩展性 中介者模式中的角色 1、中介者Mediator负责协调对象之间的交互关系通过中介者对象来通知其他对象 2、同事Colleague维护一个对中介者对象的引用通过中介者对象进行通信 代码 import java.util.ArrayList; import java.util.List; ​ // 中介者接口 interface Mediator {void sendMessage(String message, Colleague colleague); } ​ // 具体中介者 class ConcreteMediator implements Mediator {private ListColleague colleagues; ​public ConcreteMediator() {colleagues new ArrayList();} ​public void addColleague(Colleague colleague) {colleagues.add(colleague);} ​Overridepublic void sendMessage(String message, Colleague colleague) {for (Colleague col : colleagues) {// 排除发送者自身if (col ! colleague) {col.receiveMessage(message);}}} } ​ // 同事接口 interface Colleague {void sendMessage(String message); ​void receiveMessage(String message); } ​ // 具体同事类 class ConcreteColleague implements Colleague {private Mediator mediator; ​public ConcreteColleague(Mediator mediator) {this.mediator mediator;} ​Overridepublic void sendMessage(String message) {mediator.sendMessage(message, this);} ​Overridepublic void receiveMessage(String message) {System.out.println(Received message: message);} } ​ public class Main {public static void main(String[] args) {ConcreteMediator mediator new ConcreteMediator(); ​ConcreteColleague colleague1 new ConcreteColleague(mediator);ConcreteColleague colleague2 new ConcreteColleague(mediator); ​mediator.addColleague(colleague1);mediator.addColleague(colleague2); ​colleague1.sendMessage(Hello, colleague2!);colleague2.sendMessage(Hi, colleague1!);} } 中介者模式和观察者模式对比 学完这两种设计模式我们会发现两种设计模式其实是有很多相似的地方的。 1、中介者模式发消息其实是针对的发的类似QQ聊天中的单聊。 2、观察者模式发消息是广播式的发类似QQ聊天中的群聊 这里又可以放入消息队列中 观察者模式类似于fanout交换机在观察者模式中一个被观察者对象通常称为主题或者被观察者可以同时通知多个观察者对象就像fanout交换机一样它会将消息广播给所有与之绑定的队列。每个观察者对象都会收到相同的消息并且它们之间的关系是松散耦合的。 中介者模式类似于direct交换机在中介者模式中对象之间的通信通过一个中介者进行中介者根据消息的内容将消息传递给特定的对象就像direct交换机一样它会根据消息的路由键将消息发送到与之匹配的队列。这种方式下对象之间的关系是通过中介者来进行管理和协调的。 总结 要点总结 中介者模式通过引入中介者对象来减少对象之间的直接耦合。 中介者模式可以降低系统的复杂性提高系统的可维护性和可扩展性。 中介者模式的核心在于中介者对象它负责协调和管理对象之间的交互关系。 同事对象通过中介者对象来进行通信不再直接相互依赖。 使用场景 中介者模式适用于多个对象之间存在复杂的交互关系但是又不希望它们之间相互耦合的场景例如图形用户界面中的控件之间的交互、多人协作系统中的用户之间的通信等。 备忘录模式 可以将备忘录模式理解为一种通过存储对象状态并能够改变状态的设计模式 介绍 1. 备忘录模式在不破坏封装性的前提下捕获一个对象内部状态并在对象之外报错这个状态。这样就可以将该对象恢复到原先保存状态 2. 备忘录对象主要用来记录一个对象的某种状态/某些数据当要回退时可以从备忘录对象获取原来的数据进行恢复操作 3. 属于行为型模式 角色 1. 发起人Originator负责创建备忘录对象将其状态保存到备忘录中并从备忘录中恢复状态。 2. 备忘录Memento用于存储发起人对象的内部状态通常提供对状态的访问方法。 3. 管理者Caretaker负责保存备忘录对象但不会对备忘录的内容进行操作或者检查。 使用流程 1. 发起人创建备忘录对象并将其内部状态保存到备忘录中。 2. 管理者保存备忘录对象。 3. 在需要时发起人从备忘录中恢复状态。 代码 结合备忘录模式和代理模式实现一个简单的文档编辑器。编辑器包含一个文本输入框用户可以在文本输入框中输入内容。我们将使用代理模式来控制对文本输入框的访问并使用备忘录模式来保存文本输入框的历史状态以便用户可以撤销操作。 import java.util.Stack;// 备忘录类 class TextMemento {private String text;public TextMemento(String text) {this.text text;}public String getText() {return text;} }// 发起人类 class TextEditor {private String text;private StackTextMemento history;public TextEditor() {this.text ;this.history new Stack();}public void setText(String text) {this.text text;}public String getText() {return text;}public void save() {history.push(new TextMemento(text));}public void undo() {if (!history.isEmpty()) {text history.pop().getText();}} }// 代理类 class TextEditorProxy {private TextEditor editor;public TextEditorProxy() {this.editor new TextEditor();}public void setText(String text) {editor.setText(text);}public String getText() {return editor.getText();}public void save() {editor.save();}public void undo() {editor.undo();} }public class Main {public static void main(String[] args) {TextEditorProxy editor new TextEditorProxy();// 用户输入文本editor.setText(Hello, World!);// 用户保存当前文本状态editor.save();// 用户继续输入文本editor.setText(This is a text editor.);// 用户再次保存当前文本状态editor.save();// 用户进行撤销操作editor.undo();System.out.println(Current text: editor.getText());} } 小结 个人理解备忘录模式就是一种用来保存某类对象某个状态的模式。 备忘录模式的主要目的是允许在不暴露对象内部结构的情况下捕获和恢复对象的状态。这种模式常用于需要在某个时间点保存对象状态并在需要时将其恢复的情况下。   1. 优点 - 备忘录模式使得发起人对象的状态保存与恢复得以分离提高了系统的封装性和灵活性。   - 可以通过备忘录模式实现撤销操作使得用户可以在操作错误时进行恢复。 2. 缺点    - 如果备忘录对象过多或者状态信息过大可能会导致内存消耗较大。    - 备忘录模式可能会增加系统的复杂性特别是在需要管理多个备忘录对象时。 3. 为了节约内存备忘录模式可以和原型模式配合使用 解释器模式Interpreter模式 可以理解解释器模式是一种定义一种语言文法的表示并提供一个解释器来解释这种语言的语句的设计模式 介绍 是一种行为型设计模式。用于定义一个语言的文法并提供解释器来解释该语言中的句子 目的用于解释一种特定语言的语法规则并提供方法来解释和执行该语言中的矩阵。 使用例子编译器、运算表达式计算、正则表达式、机器人等 角色 抽象表达式Abstract Expression定义一个解释器的接口其中包括一个解释方法用于解释语言中的句子。 抽象表达式声明一个抽象的解释操作为抽象语法树中所有节点所共享 终结符表达式Terminal Expression实现抽象表达式接口的类用于解释语言中的终结符或基本元素。 实现文法中的终结符相关的解释操作 非终结符表达式Non-terminal Expression实现抽象表达式接口的类用于解释语言中的非终结符或复合元素。 为文法中的非终结符实现解释操作 上下文Context包含了需要解释的语句或表达式的信息提供给解释器进行解释。 环境角色含有解释器之外的全局信息 使用流程 客户端创建一个上下文对象并在上下文中设置需要解释的语句或表达式。 客户端创建解释器对象并将上下文对象传递给解释器。 解释器根据语言的文法规则逐步解释并执行语句或表达式生成最终的结果。 输入Context he TerminalExpression 信息通过Client输入即可。 代码 package com.pxl.test.Designpattern; ​ import java.util.Stack; ​ // 抽象表达式接口 interface Expression {int interpret(); } ​ // 终结符表达式数字 class Number implements Expression {private int value; ​public Number(int value) {this.value value;} ​Overridepublic int interpret() {return value;} } ​ // 非终结符表达式算术运算符表达式 class ArithmeticOperator implements Expression {private Expression leftOperand;private Expression rightOperand;private char operator; ​public ArithmeticOperator(Expression leftOperand, Expression rightOperand, char operator) {this.leftOperand leftOperand;this.rightOperand rightOperand;this.operator operator;} ​Overridepublic int interpret() {if (operator ) {return leftOperand.interpret() rightOperand.interpret();} else if (operator -) {return leftOperand.interpret() - rightOperand.interpret();}// Handle other operators if neededreturn 0;} } ​ // 上下文类 class Context {public StackExpression stack new Stack(); ​public void pushExpression(Expression expression) {stack.push(expression);} ​public Expression popExpression() {return stack.pop();} ​public boolean isOperator(Expression expression) {return expression instanceof ArithmeticOperator;} } ​ // 解释器 class Parser {private Context context; ​public Parser(Context context) {this.context context;} ​public int parse(String input) {String[] tokens input.split(\\s);for (String token : tokens) {if (.equals(token)) {Expression rightOperand context.popExpression();Expression leftOperand context.popExpression();context.pushExpression(new ArithmeticOperator(leftOperand, rightOperand, ));} else if (-.equals(token)) {Expression rightOperand context.popExpression();Expression leftOperand context.popExpression();context.pushExpression(new ArithmeticOperator(leftOperand, rightOperand, -));} else {context.pushExpression(new Number(Integer.parseInt(token)));}} ​return context.popExpression().interpret();} } ​ public class ExpressionMain {public static void main(String[] args) {String input 3 4 - 5 ;Context context new Context();Parser parser new Parser(context);int result parser.parse(input);System.out.println(Result: result); // 输出} } 在SpelExpressionParser类中的使用 public class Test {public static void main(String[] args) {SpelExpressionParser parser new SpelExpressionParser();Expression expression parser.parseExpression(10 *(21));int value (int) expression.getValue();System.out.println(value);} } 小结 个人理解解释器模式通过定义一些基本元素和操作终结符表达式和一些复杂规则非终结符表达式让解释器进行解释获得想要的结果 解释器模式确实通过定义基本元素和操作终结符表达式以及复杂规则非终结符表达式来构建解释器从而实现对给定语言或语法的解释和执行。终结符表达式代表了文法中的最基本的元素或操作而非终结符表达式则表示了文法中的复杂规则或组合规则。通过将这些表达式组合起来解释器能够解释和执行整个语言表达式从而得到最终的结果。 优点 简化了语言的解释和执行过程使得添加新的语法规则或扩展现有规则变得容易。 易于实现和理解对于特定领域的语言解释非常高效。 缺点 难以维护复杂的文法规则特别是文法变化频繁或文法非常复杂时。 可能会导致类的数量急剧增加增加了系统的复杂性。 状态模式 可以理解状态模式是一种不断改变状态改变类本质的设计模式如一个人一样小时候和长大后是不同的状态了但是还是同一个人。 介绍 1、状态模式主要来解决对象在多种状态转换时需要对外输出不同行为的问题。状态和行为是一一对应的状态之间可以互相转换 2、当一个对象的内在状态改变时允许改变其行为这个对象看起来可以举例称一个人小时候和长大后状态不同了但是还是同一个人 原理类图 说明 1、Context类为环境角色用于维护State实例这个实例定义当前状态 2、State是抽象状态角色定义一个接口封装与Context的一个特点接口相关行为 3、ConcreteState具体的状态角色每个子类实现一个与Context的一个状态相关行为 代码 状态模式用于管理抽奖的不同状态包括初始状态、中奖状态和未中奖状态。每个状态都实现了LotteryState接口并实现了对应的抽奖逻辑。LotteryContext类用于维护当前的状态并委托给当前状态处理抽奖操作。在测试类中进行了5次抽奖操作每次抽奖都会根据当前状态执行相应的逻辑。 下面代码中不断的在setState将它的类在进行转变从初始化状态类转变成未中奖/中奖类 package com.pxl.test.Designpattern; ​ // 定义抽奖状态接口 interface LotteryState {void draw(LotteryContext context); } ​ // 初始状态 class InitialState implements LotteryState {Overridepublic void draw(LotteryContext context) {// 在初始状态下可以进行抽奖System.out.println(正在抽奖请稍候...第一次初始化状态。。。);// 模拟抽奖逻辑int luckyNumber (int) (Math.random() * 100);if (luckyNumber 50) {System.out.println(恭喜你中奖了);context.setState(new WinnerState()); // 切换到中奖状态} else {System.out.println(很遗憾你没有中奖。);context.setState(new NotWinnerState()); // 切换到未中奖状态}} } ​ // 中奖状态 class WinnerState implements LotteryState {Overridepublic void draw(LotteryContext context) {// 已经中奖了不能再抽奖System.out.println(你已经中过奖了请等待下一次抽奖。);} } ​ // 未中奖状态 class NotWinnerState implements LotteryState {Overridepublic void draw(LotteryContext context) {// 在未中奖状态下可以进行抽奖System.out.println(正在抽奖请稍候...);// 模拟抽奖逻辑int luckyNumber (int) (Math.random() * 100);if (luckyNumber 50) {System.out.println(恭喜你中奖了);context.setState(new WinnerState()); // 切换到中奖状态} else {System.out.println(很遗憾你没有中奖。);}} } ​ // 抽奖上下文 class LotteryContext {private LotteryState state; ​public LotteryContext() {this.state new InitialState(); // 初始状态为初始状态} ​public void setState(LotteryState state) {this.state state;} ​public void draw() {state.draw(this); // 委托状态处理抽奖操作} } ​ // 测试类 public class StateMain {public static void main(String[] args) {LotteryContext context new LotteryContext(); ​// 进行5次抽奖for (int i 0; i 5; i) {context.draw();System.out.println(---------------------------------);}} } ​ 小结 个人理解 状态模式是一种不断改变自己状态就是不断通过接口实现类进行转变实现系统灵活性的模式。 优化点将枚举类代替状态类避免类爆炸。但是要注意的是这种会违反开闭原则 状态模式通过定义不同的状态类以及相应的状态转换规则使得对象能够根据内部状态的改变而改变自身的行为。这种动态的状态转换使得系统具有了更大的灵活性和可扩展性。通过接口实现类之间的转变状态模式使得系统可以在运行时根据需求动态地改变对象的状态而不需要修改对象的代码。这种灵活性使得状态模式在需要对象根据不同条件改变行为的场景中非常有用。 状态模式是一种强大的设计模式但它也有其优点和缺点。 优点 清晰的状态转换状态模式将每个状态封装到一个类中使得状态之间的转换变得清晰明确易于理解和维护。 简化条件判断通过将状态的行为抽象为独立的类状态模式消除了长串的条件判断语句使得代码更加简洁清晰。 符合开闭原则状态模式通过封装每个状态和状态之间的转换规则使得新增状态或者修改现有状态的行为变得容易符合开闭原则。 提高可扩展性状态模式使得系统在不同状态下可以拥有不同的行为新增状态只需要添加新的状态类而不需要修改现有代码提高了系统的可扩展性。 促进了模块化设计每个状态都被封装成一个独立的类使得系统更加模块化每个模块负责一个特定的状态易于理解和维护 缺点 可能导致类爆炸当系统中存在大量的状态时可能会导致类的数量急剧增加使得系统变得复杂。因此在设计状态模式时需要合理把握状态的数量。 增加了系统复杂性状态模式引入了多个状态类和状态之间的转换规则可能会增加系统的复杂性使得理解和维护变得困难。 不适用于简单状态转换如果系统中仅有少量的状态且状态之间的转换比较简单使用状态模式可能会显得过于繁琐不适合于简单的状态转换场景。 可能导致对象间的依赖增加当状态对象需要访问其他对象的状态或者信息时可能会导致状态对象之间的依赖增加使得系统变得复杂。 使用场景 对象行为随状态变化而变化 条件语句导致代码复杂避免大量条件判断 各个状态类之间相互独立 例如说在借阅平台中状态从审核 - 借阅 -归还 策略模式 策略模式是一种通过改变策略改变执行方式的设计模式 介绍 1、策略模式Strategy Pattern是一种行为设计模式它允许在运行时选择算法的行为。它将算法封装成独立的类使得它们可以相互替换而不会影响客户端使用算法的方式。 2、把变化的代码从不变的代码中分离开针对接口编程而不是具体类定义了策略接口多用组合/聚合少用继承客户通过组合方法实现策略 代码 DiscountStrategy 是策略接口定义了抽象的折扣计算方法。然后我们有三个具体的策略类实现了这个接口分别是NoDiscountStrategy、FixedDiscountStrategy和ThresholdDiscountStrategy分别代表无折扣、固定折扣和满减折扣。ShoppingCart 类作为上下文类接受一个折扣策略作为参数然后根据具体的策略计算最终的价格。通过这种方式客户端可以轻松地切换不同的折扣策略而不需要修改ShoppingCart类的代码。 package com.pxl.test.Designpattern; ​ // 策略接口 interface DiscountStrategy {double applyDiscount(double totalPrice); } ​ // 第一个具体策略类无折扣 class NoDiscountStrategy implements DiscountStrategy {Overridepublic double applyDiscount(double totalPrice) {return totalPrice;} } ​ // 第二个具体策略类固定折扣 class FixedDiscountStrategy implements DiscountStrategy {private double discountRate; ​public FixedDiscountStrategy(double discountRate) {this.discountRate discountRate;} ​Overridepublic double applyDiscount(double totalPrice) {return totalPrice - (totalPrice * discountRate);} } ​ // 第三个具体策略类满减折扣 class ThresholdDiscountStrategy implements DiscountStrategy {private double threshold;private double discountAmount; ​public ThresholdDiscountStrategy(double threshold, double discountAmount) {this.threshold threshold;this.discountAmount discountAmount;} ​Overridepublic double applyDiscount(double totalPrice) {if (totalPrice threshold) {return totalPrice - discountAmount;}return totalPrice;} } ​ // 上下文类用于选择和应用具体的策略 class ShoppingCart {private DiscountStrategy discountStrategy; ​public ShoppingCart(DiscountStrategy discountStrategy) {this.discountStrategy discountStrategy;} ​public double checkout(double totalPrice) {return discountStrategy.applyDiscount(totalPrice);} } ​ // 客户端代码 public class StrategyMain {public static void main(String[] args) {ShoppingCart cart1 new ShoppingCart(new NoDiscountStrategy());ShoppingCart cart2 new ShoppingCart(new FixedDiscountStrategy(0.1));ShoppingCart cart3 new ShoppingCart(new ThresholdDiscountStrategy(100, 20)); ​double totalPrice1 100;double totalPrice2 200;double totalPrice3 150; ​System.out.println(Cart 1 Total Price: cart1.checkout(totalPrice1));System.out.println(Cart 2 Total Price: cart2.checkout(totalPrice2));System.out.println(Cart 3 Total Price: cart3.checkout(totalPrice3));} } ​ 策略模式在Arrays中的使用 策略模式在Arraysp排序的时候使用到了策略模式。 分析 Integer[] data new Integer[]{3,2,1,5,4};ComparatorInteger comparator new Comparator() {Overridepublic int compare(Integer o1, Integer o2) {return o1 o2 ? 1 : -1;}};Arrays.sort(data,comparator);for (Integer datum : data) {System.out.print(datum );} 上述代码就用到了策略Arrays.sort(data,comparator);中的comparator采用了升序策略。 我们直接点击sort的源码 小结 个人理解策略模式是通过一个上下文类来聚合一个策略接口并灵活的调用想要的策略。 策略模式通过将算法封装在独立的策略类中并让上下文类持有一个策略接口的引用实现了算法的灵活组合和调用。这种设计使得客户端可以根据需求选择并切换不同的策略而不需要修改上下文类的代码从而提高了代码的灵活性和可维护性。 作用 允许在运行时动态地选择算法。 将算法的实现与使用它的客户端代码分离提高了代码的灵活性和可维护性。 通过使用接口和多态实现了松耦合。 符合的原则 开闭原则Open/Closed Principle策略模式通过定义算法族并使它们之间可以相互替换从而在不修改原有代码的情况下添加新的算法。 单一责任原则Single Responsibility Principle每个策略类只负责一个特定的算法或行为。 优点 提供了更好的扩展性可以轻松地添加新的算法或修改现有的算法。 提高了代码的可读性和可维护性因为每个算法都被封装在一个独立的类中。 可以在运行时动态地选择算法使得客户端代码更加灵活。 缺点 增加了类的数量可能会导致代码变得复杂。 客户端需要了解所有的策略类可能会增加学习和理解的成本。 职责链模式责任链模式 可以理解职责链设计模式理解成一种链式处理请求的设计模式 介绍 1、职责链模式为请求创建一个接收者对象的链。这种模式对请求的发送者和接收者进行解耦 2、职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求那么它会把相同的请求传给下一个接收者依次类推。 代码 报销请求首先传递给经理Manager如果金额小于等于1000则经理会直接批准否则请求会继续传递给部门主管Department Supervisor如果金额小于等于5000则部门主管批准否则请求会继续传递给财务主管Financial Manager。 package com.pxl.test.Designpattern; ​ // 请求类 class ReimbursementRequest {private double amount;public ReimbursementRequest(double amount) {this.amount amount;}public double getAmount() {return amount;} } ​ // 处理者接口 interface Handler {void processRequest(ReimbursementRequest request); } ​ // 具体处理者类 class Manager implements Handler {private Handler nextHandler; ​public Manager(Handler nextHandler) {this.nextHandler nextHandler;} ​Overridepublic void processRequest(ReimbursementRequest request) {if (request.getAmount() 1000) {System.out.println(Manager approves the reimbursement request.);} else {nextHandler.processRequest(request);}} } ​ class DepartmentSupervisor implements Handler {private Handler nextHandler; ​public DepartmentSupervisor(Handler nextHandler) {this.nextHandler nextHandler;} ​Overridepublic void processRequest(ReimbursementRequest request) {if (request.getAmount() 5000) {System.out.println(Department Supervisor approves the reimbursement request.);} else {nextHandler.processRequest(request);}} } ​ class FinancialManager implements Handler {Overridepublic void processRequest(ReimbursementRequest request) {System.out.println(Financial Manager approves the reimbursement request.);} } ​ // 客户端 public class ChainOfResponsibilityClient {public static void main(String[] args) {// 构建处理者链Handler financialManager new FinancialManager();Handler departmentSupervisor new DepartmentSupervisor(financialManager);Handler manager new Manager(departmentSupervisor); ​// 创建报销请求ReimbursementRequest request1 new ReimbursementRequest(800);ReimbursementRequest request2 new ReimbursementRequest(3500);ReimbursementRequest request3 new ReimbursementRequest(10000); ​// 发送请求manager.processRequest(request1);manager.processRequest(request2);manager.processRequest(request3);} } 职责链模式在SpringMVC框架中的应用 在拦截器中使用到了。从核心类DispatcherServlet追。 职责链模式可以被理解为一种链式处理问题的解决方案。在职责链模式中请求被传递到处理者链上的每个处理者直到有一个处理者能够处理该请求为止。这种处理方式形成了一种链式的结构因此被称为职责链模式。 总结 优点 解耦性请求的发送者和接收者之间解耦发送者不需要知道具体的接收者。 可扩展性可以方便地新增或调整处理者链以满足不同的需求。 灵活性可以动态地改变处理者链的顺序或组成以满足不同的请求处理流程。 单一职责原则每个处理者只需要关注自己能够处理的请求不需要关注其他请求。 缺点 请求可能未被处理如果整条处理者链都不能处理请求那么请求可能会未被处理。 性能问题当处理者链过长时可能会影响性能。 调试困难由于请求的处理流程是动态的因此调试起来可能会比较困难