第二十五章访问者模式

最新推荐文章于 2023-07-05 14:25:20 发布

阿川xiang

最新推荐文章于 2023-07-05 14:25:20 发布

阅读量116

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/weixin_43054590/article/details/100785975

版权

设计模式专栏收录该内容

25 篇文章 0 订阅

订阅专栏

一、模式示例

1.1、原理

1、定义

在访问者模式（Visitor Pattern）中，我们使用了一个访问者类，它改变了元素类的执行算法。通过这种方式，元素的执行算法可以随着访问者改变而改变。这种类型的设计模式属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象上的操作。

2、介绍

意图：主要将数据结构与数据操作分离。
主要解决：稳定的数据结构和易变的操作耦合问题。
何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，使用访问者模式将这些封装到类中。
如何解决：在被访问的类里面加一个对外提供接待访问者的接口。
关键代码：在数据基础类里面有一个方法接受访问者，将自身引用传入访问者。
应用实例：您在朋友家做客，您是访问者，朋友接受您的访问，您通过朋友的描述，然后对朋友的描述做出一个判断，这就是访问者模式。
优点：
1、符合单一职责原则。
2、优秀的扩展性。
3、灵活性。
缺点：
1、具体元素对访问者公布细节，违反了迪米特原则。
2、具体元素变更比较困难。
3、违反了依赖倒置原则，依赖了具体类，没有依赖抽象。
使用场景：
1、对象结构中对象对应的类很少改变，但经常需要在此对象结构上定义新的操作。
2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作"污染"这些对象的类，也不希望在增加新操作时修改这些类。
注意事项：访问者可以对功能进行统一，可以做报表、UI、拦截器与过滤器。

3、UML图

在这里插入图片描述

1.2、代码

1、定义一个表示元素的接口

public interface ComputerPart {
   public void accept(ComputerPartVisitor computerPartVisitor);
}

2、创建扩展了上述类的实体类

public class Keyboard  implements ComputerPart {
 
   @Override
   public void accept(ComputerPartVisitor computerPartVisitor) {
      computerPartVisitor.visit(this);
   }
}

public class Monitor  implements ComputerPart {
 
   @Override
   public void accept(ComputerPartVisitor computerPartVisitor) {
      computerPartVisitor.visit(this);
   }
}

public class Mouse  implements ComputerPart {
 
   @Override
   public void accept(ComputerPartVisitor computerPartVisitor) {
      computerPartVisitor.visit(this);
   }
}

public class Computer implements ComputerPart {
   
   ComputerPart[] parts;
 
   public Computer(){
      parts = new ComputerPart[] {new Mouse(), new Keyboard(), new Monitor()};      
   } 
 
 
   @Override
   public void accept(ComputerPartVisitor computerPartVisitor) {
      for (int i = 0; i < parts.length; i++) {
         parts[i].accept(computerPartVisitor);
      }
      computerPartVisitor.visit(this);
   }
}

3、定义一个表示访问者的接口

public interface ComputerPartVisitor {
   public void visit(Computer computer);
   public void visit(Mouse mouse);
   public void visit(Keyboard keyboard);
   public void visit(Monitor monitor);
}

4、创建实现了上述类的实体访问者

public class ComputerPartDisplayVisitor implements ComputerPartVisitor {
 
   @Override
   public void visit(Computer computer) {
      System.out.println("Displaying Computer.");
   }
 
   @Override
   public void visit(Mouse mouse) {
      System.out.println("Displaying Mouse.");
   }
 
   @Override
   public void visit(Keyboard keyboard) {
      System.out.println("Displaying Keyboard.");
   }
 
   @Override
   public void visit(Monitor monitor) {
      System.out.println("Displaying Monitor.");
   }
}

5、使用 ComputerPartDisplayVisitor 来显示 Computer 的组成部分

public class VisitorPatternDemo {
   public static void main(String[] args) {
 
      ComputerPart computer = new Computer();
      computer.accept(new ComputerPartDisplayVisitor());
   }
}

6、测试结果

Displaying Mouse.
Displaying Keyboard.
Displaying Monitor.
Displaying Computer.

1.3、设计模式六大基本原则

单一原则（Single Responsibility Principle）：一个类只负责一项职责，尽量做到类的只有一个行为原因引起变化；a、业务对象（BO business object）、业务逻辑（BL business logic）拆分；
里氏替换原则（LSP liskov substitution principle）：子类可以扩展父类的功能，但不能改变原有父类的功能；（目的：增强程序的健壮性）实际项目中，每个子类对应不同的业务含义，使父类作为参数，传递不同的子类完成不同的业务逻辑。
依赖倒置原则（dependence inversion principle）：面向接口编程；（通过接口作为参数实现应用场景）抽象就是接口或者抽象类，细节就是实现类；含义：上层模块不应该依赖下层模块，两者应依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象；【接口负责定义public属性和方法，并且申明与其他对象依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑】
接口隔离（interface segregation principle）：建立单一接口；（扩展为类也是一种接口，一切皆接口）定义：a.客户端不应该依赖它不需要的接口；b.类之间依赖关系应该建立在最小的接口上；
【接口的设计粒度越小，系统越灵活，但是灵活的同时结构复杂性提高，开发难度也会变大，维护性降低】
迪米特原则（law of demeter LOD）：最少知道原则，尽量降低类与类之间的耦合；一个对象应该对其他对象有最少的了解