“行为变化"模式
使用场景
在组件的构建过程中,组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦,从而支
持组件行为的变化,实现两者之间的松耦合。
典型模式
command
visitor
Command 命令模式
命令模式(Command Pattern)是一种数据驱动的设计模式,它属于行为型模式。请求以命令的形式包裹在对象中,并传给调用对象。调用对象寻找可以处理该命令的合适的对象,并把该命令传给相应的对象,该对象执行命令。
意图:将一个请求封装成一个对象,从而使您可以用不同的请求对客户进行参数化。
主要解决:在软件系统中,行为请求者与行为实现者通常是一种紧耦合的关系,但某些场合,比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合适。
何时使用:在某些场合,比如要对行为进行"记录、撤销/重做、事务"等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将"行为请求者"与"行为实现者"解耦?将一组行为抽象为对象,可以实现二者之间的松耦合。
如何解决:通过调用者调用接受者执行命令,顺序:调用者→接受者→命令。
关键代码:定义三个角色:1、received 真正的命令执行对象 2、Command 3、invoker 使用命令对象的入口
应用实例:struts 1 中的 action 核心控制器 ActionServlet 只有一个,相当于 Invoker,而模型层的类会随着不同的应用有不同的模型类,相当于具体的 Command。
优点: 1、降低了系统耦合度。 2、新的命令可以很容易添加到系统中去。
缺点:使用命令模式可能会导致某些系统有过多的具体命令类。
使用场景:认为是命令的地方都可以使用命令模式,比如: 1、GUI 中每一个按钮都是一条命令。 2、模拟 CMD。
注意事项:系统需要支持命令的撤销(Undo)操作和恢复(Redo)操作,也可以考虑使用命令模式,见命令模式的扩展。
使用场景
在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重做(undo/redo)、 事务”等处理,这种无法抵御变化的紧耦合是不合适的。“行为请求者”与“行为实现者”解耦,可以将一组行为抽象为对象,可以实现二者之间的松耦合。
模式定义
将一个请求(行为)封装为一个对象,从而可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
类图结构
代码举例
//命令模式的基础构造
public interface Command {
void execute();
}
public class CutCommand implements Command {
String arg;
public CutCommand(String arg) {
this.arg = arg;
}
@Override
public void execute() {
System.out.print("#cut process..." + arg + "\n");
}
}
public class CopyCommand implements Command {
String arg;
public CopyCommand(String arg) {
this.arg = arg;
}
@Override
public void execute() {
System.out.print("#copy process..." + arg + "\n");
}
}
public class PasteCommand implements Command {
String arg;
public PasteCommand(String arg) {
this.arg = arg;
}
@Override
public void execute() {
System.out.print("#paste process..." + arg + "\n");
}
}
public class DeleteCommand implements Command {
String arg;
public DeleteCommand(String arg) {
this.arg = arg;
}
@Override
public void execute() {
System.out.print("#delete process..." + arg + "\n");
}
}
//宏命令 使用了组合模式
public class MacroCommand implements Command {
Vector<Command> commands=new Vector<Command>();
public void addCommand(Command c) {
commands.add(c);
}
@Override
public void execute() {
for (Command c : commands) {
c.execute();
}
}
}
public class ClientApp{
public static void main(String args[]) {
CutCommand command1=new CutCommand("Arg ###");
CopyCommand command2=new CopyCommand("Arg $$$");
MacroCommand macro=new MacroCommand();
macro.addCommand(command1);
macro.addCommand(command2);
macro.execute();
}
}
要点总结
Command模式的根本目的在于将“行为请求者”与“行为实现者”解耦,在面向对象语言中,常见的实现手段是“将行为抽象为对象”。
实现Command接口的具体命令对象ConcreteCommand有时候根据需要可能会保存一些额外的状态信息。 通过使用Composite模式,可以将多个“命令’'封装为一一个“复合命令"MacroCommand。
Command模式与C++中的函数对象有些类似。但两者定义行为接口的规范有所区别: Command以面向对象中的“接口-实现"来定义行为接口规范,更严格,但有性能损失; C++函数对象以函数签名来定义行为接口规范,更灵活,性能更高。
Visitor 访问者模式
在访问者模式(Visitor Pattern)中,我们使用了一个访问者类,它改变了元素类的执行算法。通过这种方式,元素的执行算法可以随着访问者改变而改变。这种类型的设计模式属于行为型模式。根据模式,元素对象已接受访问者对象,这样访问者对象就可以处理元素对象上的操作。
意图:主要将数据结构与数据操作分离。
主要解决:稳定的数据结构和易变的操作耦合问题。
何时使用:需要对一个对象结构中的对象进行很多不同的并且不相关的操作,而需要避免让这些操作"污染"这些对象的类,使用访问者模式将这些封装到类中。
如何解决:在被访问的类里面加一个对外提供接待访问者的接口。
关键代码:在数据基础类里面有一个方法接受访问者,将自身引用传入访问者。
应用实例:您在朋友家做客,您是访问者,朋友接受您的访问,您通过朋友的描述,然后对朋友的描述做出一个判断,这就是访问者模式。
优点: 1、符合单一职责原则。 2、优秀的扩展性。 3、灵活性。
缺点: 1、具体元素对访问者公布细节,违反了迪米特原则。 2、具体元素变更比较困难。 3、违反了依赖倒置原则,依赖了具体类,没有依赖抽象。
使用场景: 1、对象结构中对象对应的类很少改变,但经常需要在此对象结构上定义新的操作。 2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作,而需要避免让这些操作"污染"这些对象的类,也不希望在增加新操作时修改这些类。
注意事项:访问者可以对功能进行统一,可以做报表、UI、拦截器与过滤器。
使用场景
在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改,将会
给子类带来很繁重的变更负担,甚至破坏原有设计。
模式定义
表示一个作用于某对象结构中的各元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)。
类图结构
代码举例
public abstract class Element{
public abstract void func1();
//想给子类 再添加一个行为方法 可以这样子添加
//这样存在缺陷 所有子类都必须实现该方法
//软件开发过程中 可以这样子 如果是维护系统新加需求 这样就很麻烦了 违背开闭原则
public abstract void func2(int data);
}
public class ElementA extends Element{
@Override
public void func1() {
//...
}
//新添加的
@Override
public void func2(int data){
}
}
public class ElementB extends Element{
@Override
public void func1() {
//***
}
//新添加的
@Override
public void func2(int data){
}
}
进行代码重构
public abstract class Element{
//......
public abstract void accept(Visitor visitor);//第一次多态辨析
}
//Element 有多少个子类 Visitor内就有多少个方法
public class ElementA extends Element{
//......
@Override
public void accept(Visitor visitor) {
visitor.visitElementA(this);
}
}
public class ElementB extends Element{
@Override
public void accept(Visitor visitor) {
visitor.visitElementB(this);//第二次多态辨析
}
}
//表示一个作用于某对象结构中的各元素的操作
public abstract class Visitor{
public abstract void visitElementA(ElementA element);
public abstract void visitElementB(ElementB element);
}
//上方代码是稳定的
//==================================
//下方代码是变化的
//扩展1
public class Visitor1 extends Visitor{
@Override
public void visitElementA(ElementA element) {
System.out.println("Visitor1 is processing ElementA");
}
@Override
public void visitElementB(ElementB element) {
System.out.println("Visitor1 is processing ElementB");
}
}
//扩展2
public class Visitor2 extends Visitor{
@Override
public void visitElementA(ElementA element) {
System.out.println("Visitor2 is processing ElementA");
}
@Override
public void visitElementB(ElementB element) {
System.out.println("Visitor2 is processing ElementB");
}
}
public class ClientApp{
public static void main(String args[]) {
Visitor2 visitor=new Visitor2();
ElementB elementB=new ElementB();
elementB.accept(visitor);// 该行代码调用的时候 有两次动态代码辨析
ElementA elementA=new ElementA();
elementA.accept(visitor);
}
}
类图结构中 ObjectStructure,Element,ConcreteElementA和ConcreteElementB,Visitor是稳定的。
ConcreteVisitor1 和 ConcreteVisitor2 是变化的。
要点总结
Visitor模式通过所谓双重分发(double dispatch) 来实现在不更改(不添加新的操作-编译时) Element类 层次结构的前提下,在运行时透明地为类层次结构上的各个类动态添加新的操作(支持变化)。
所谓双重分发即Visitor模式中间包括了两个多态分发(注意其中的多态机制) :第一个为accept方法的多态辨析;第二个为visitElementX方法的多态辨析。
Visitor模式的最大缺点在于扩展类层次结构(增添新的Element子类),会导致Visitor类的改变。因此Vistor模式适用于“Element类层次结构稳定,而其中的操作却经常面临频繁改动”。