设计模式-行为型-中介者模式(Mediator)
参考文献
https://www.oodesign.com/mediator-pattern
https://refactoringguru.cn/design-patterns/mediator
中介者模式
定义一个对象来封装一组对象如何交互。中介器通过防止对象显式地相互引用来促进松散耦合,并且它允许您独立地改变它们的交互。
中介器通过强制类的通信流通过中介对象来解耦一组类。
组件
Mediator- 定义与 Colleague 对象通信的接口。
ConcreteMediator - 了解Colleague 类并保留对Colleague 对象的引用。
实现Colleague类之间的通信和消息传递
Colleague classes- 保留对其 Mediator 对象的引用
每当它本来可以与其他Colleague进行通信时,就与调解器进行通信。
实现方式
确定需要解耦的一组当前紧密耦合的类,这些类之间存在复杂的交互关系。
声明一个中介者接口,并在该接口中描述中介者和各个组件之间所需的交流接口。通常情况下,一个接收组件通知的方法就足够了。
实现具体的中介者类,该 ...
设计模式-创建型-解释器模式(Interpreter)
参考文献
https://www.oodesign.com/interpreter-pattern
解释器模式
用于将特定语言或问题领域的表达式转换为可执行的代码.它包括一个上下文对象、抽象表达式和具体表达式.
解释器模式的应用范围有限.此模式可应用于解析简单语法中定义的轻量表达式,有时也可应用于简单规则引擎中定义的轻量表达式.
组件
上下文(Context):上下文对象保存解释器的全局信息和状态,它在解释过程中提供解释器需要的环境变量和数据.
抽象表达式(Abstract Expression):抽象表达式定义了一个通用的解释操作接口,该接口通常包括一个 interpret() 方法,用于解释表达式.
终结符表达式(Terminal Expression):终结符表达式是抽象表达式的子类,它代表语法规则中的终结符,也就是不再可以进一步解释的最小元素.终结符表达式通常是解释器模式的叶节点.
非终结符表达式(Nonterminal Expression):非终结符表达式是抽象表达式的子类,它代表语法规则中的非终结符,也就是可以进一步解释的元素.非终结符表达式通常包含其他 ...
设计模式-行为型-观察者模式(Observer)
参考文献
https://refactoringguru.cn/design-patterns/observer
https://www.oodesign.com/observer-pattern
https://java-design-patterns.com/patterns/observer/
观察者模式
定义对象之间的一对多依赖关系,以便当一个对象更改状态时,其所有依赖项都会收到通知并自动更新.
Model View Controller Pattern: 观察者模式用于模型视图控制器 (MVC) 架构模式.在 MVC 中,此模式用于将模型与视图解耦. View代表观察者,模型是Observable对象
Event management: 这是广泛使用观察者模式的领域之一. Swing 和.Net 广泛使用观察者模式来实现事件机制.
组件
Observable(Publisher): 定义将观察者附加到客户端和取消附加到客户端的操作的接口或抽象类.
ConcreteObservable: 具体的Observable类.它维护对象的状态,当状态发生变化时,它会通知附加的 ...
设计模式-行为型-迭代器模式(Iterator)
参考文献
https://www.oodesign.com/iterator-pattern
https://refactoringguru.cn/design-patterns/iterator
https://java-design-patterns.com/patterns/iterator/
图解设计模式 结城浩
迭代器模式
迭代器模式的思想是负责访问和传递集合的对象并将其放入迭代器对象中.迭代器对象将维护迭代的状态,跟踪当前项并具有识别下一个要迭代的元素的方法.
提供一种顺序访问聚合对象的元素而不暴露其底层表示的方法.
迭代器模式提供的抽象允许您修改集合实现,而无需在集合之外进行任何更改
组件
Iterator(迭代器) : 负责定义按顺序逐个遍历元素的接口.
ConcreteIterator(具体的迭代器) : 负责实现Iterator角色所定义的接口
Collection(集合) : 负责定义创建Iterator角色的接口.
ConcreteCollection(具体的集合) : 负责实现Collection角色所定义的接口.
实现方式
声明迭代器接 ...
设计模式-行为型-策略模式(Strategy)
参考文献
https://www.oodesign.com/strategy-pattern
https://java-design-patterns.com/patterns/strategy/
https://refactoringguru.cn/design-patterns/strategy
策略模式
定义一系列算法,封装每个算法,并使它们可以互换.策略使算法能够独立于使用它的客户端而变化.
组件
Strategy(策略): 定义所有支持的算法通用的接口. Context 使用此接口来调用 ConcreteStrategy 定义的算法.
ConcreteStrategy(具体策略): 每个具体策略都实现一个算法.它们实现了 Strategy 接口定义的方法,提供了不同的算法实现
Context(上下文)
包含对策略对象的引用.
可以定义一个接口,让策略访问其数据.
Context 对象包含对应使用的ConcreteStrategy 的引用.当需要执行操作时,算法将从策略对象运行.上下文不知道策略的实施.如有必要,可以定义附加对象以将数据从上下文对象传递到策略.
...
设计模式-行为型-备忘录模式(Memento)
参考文献
https://www.oodesign.com/memento-pattern
https://java-design-patterns.com/patterns/memento/
https://refactoringguru.cn/design-patterns/memento
备忘录模式
允许在不暴露对象实现细节的情况下保存和恢复对象之前的状态.
组件
Memento 备忘录
存储 Originator对象的内部状态.状态可以包括任意数量的状态变量.
备忘录必须具有两个接口,一个接口用于负责人(Caretaker).这个接口不能允许任何操作或者访问备忘录存储的内部状态,从而遵循封装原则.另一个接口用于原发器(Originator),允许原发器访问任何必要的状态变量以恢复先前的状态
Originator 原发器
创建一个备忘录对象,用于捕获原发器的内部状态.
使用备忘录对象来恢复先前的状态.
Caretaker 负责人
负责保持备忘录.
备忘录对于负责人来说是不透明的,而负责人不能对其进行操作.
实现方式
确定担任原发器角色的类取决于你的 ...
设计模式-行为型-状态模式(State)
参考文献
https://refactoringguru.cn/design-patterns/state
https://java-design-patterns.com/patterns/state/
状态模式
允许对象在其内部状态发生变化时改变其行为
组件
状态接口(State Interface):定义了表示各种状态的方法,具体状态类必须实现该接口.
具体状态类(Concrete State Class):实现了状态接口的具体状态类,每个具体状态类负责处理特定的状态下的行为.
上下文类(Context Class):维护一个对当前状态对象的引用,提供了用于切换状态和执行相应操作的方法.
环境类状态切换方法(Transition Methods in Context Class):在上下文类中提供了用于切换状态的方法,允许客户端自行决定何时切换状态.
共享状态(Shared State):多个上下文对象共享同一个状态对象的情况.这种情况下,可以将状态对象设计成可共享的,以减少对象的创建和内存占用.
实现方式
定义状态接口(State Interface):创 ...
设计模式-创建型-命令模式(Command)
参考文献
https://www.oodesign.com/command-pattern
https://refactoringguru.cn/design-patterns/command
https://java-design-patterns.com/patterns/command/
命令模式
它可将请求转换为一个包含与请求相关的所有信息的独立对象. 该转换让你能根据不同的请求将方法参数化、 延迟请求执行或将其放入队列中, 且能实现可撤销操作.
组件
Command - 接口通常仅声明一个执行命令的方法.
ConcreteCommand - 会实现各种类型的请求. 具体命令自身并不完成工作, 而是会将调用委派给一个业务逻辑对象. 但为了简化代码, 这些类可以进行合并.
接收对象执行方法所需的参数可以声明为具体命令的成员变量. 你可以将命令对象设为不可变, 仅允许通过构造函数对这些成员变量进行初始化.
Client - 会创建并配置具体命令对象. 客户端必须将包括接收者实体在内的所有请求参数传递给命令的构造函数. 此后, 生成的命令就可以与一个或多个发送者 ...
设计模式-行为型-责任链模式(Chain of Responsibility)
参考文献
https://www.oodesign.com/chain-of-responsibility-pattern
https://java-design-patterns.com/patterns/chain-of-responsibility/
https://refactoringguru.cn/design-patterns/chain-of-responsibility
责任链模式
允许你将请求沿着处理者链进行发送. 收到请求后, 每个处理者均可对请求进行处理, 或将其传递给链上的下个处理者.
组件
Request: 责任链中的请求对象
1public class Request{}
Handler: 定义处理请求的接口
1234public interface Handler{ boolean shouldSkip(Request request); boolean handle(Request request);}
RequestHandler: 实际处理请求的类
如果它可以处理请求,则进行处理,否则将 ...
设计模式-行为型-模版方法模式(Template Method)
参考文献
https://refactoringguru.cn/design-patterns/template-method
https://www.oodesign.com/template-method-pattern
模版方法模式
模板方法使用子类重写的抽象操作在基类中定义算法以提供具体行为.
定义操作中算法的骨架,将某些步骤推迟到子类中.
模板方法允许子类重新定义算法的某些步骤,而不让它们改变算法的结构.
模板方法模式建议将算法分解为一系列步骤, 然后将这些步骤改写为方法, 最后在 “模板方法” 中依次调用这些方法. 步骤可以是 抽象的, 也可以有一些默认的实现. 为了能够使用算法, 客户端需要自行提供子类并实现所有的抽象步骤. 如有必要还需重写一些步骤 (但这一步中不包括模板方法自身).
组件
AbstractClass(抽象类): 定义具体子类定义的抽象基元操作以实现算法的步骤.
实现定义算法骨架的模板方法.模板方法调用原始操作以及 AbstractClass 或其他对象中定义的操作
ConcreteClass(具体类): 实现原始操作以执行 ...