揭开访问者模式的神秘面纱-轻松增强对象行为

最新推荐文章于 2024-05-07 19:04:04 发布
最新推荐文章于 2024-05-07 19:04:04 发布
阅读量1.1k 收藏 40
点赞数 45
分类专栏： 设计模式 文章标签： 设计模式 访问者模式 软件工程 java 面试 程序人生
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/danci_bto/article/details/136725429
版权

在这里插入图片描述
​🌈 个人主页：danci_
🔥 系列专栏：《设计模式》
💪🏻 制定明确可量化的目标，坚持默默的做事。
🚀 转载自：探索设计模式的魅力：揭开访问者模式的神秘面纱-轻松增强对象行为

探索设计模式的魅力：揭开访问者模式的神秘面纱轻松增强对象行为

文章目录

一、案例场景🔍

1.1 经典的运用场景

    访问者模式（Visitor Pattern）是一种将算法与对象结构分离的设计模式。它允许我们为对象结构中的各种元素添加新的操作，而无需修改这些元素的类。以下是两个典型场景，其中访问者模式非常适合使用。

  • 文档编辑器的格式化操作 📄✏️：
    考虑一个复杂的文档编辑器，它支持多种文本元素，比如段落、图片、表格等。在对文档进行格式化或样式调整时，比如添加样式、导出不同格式，我们需要对这些元素进行一系列不同的操作。

    这里，访问者模式允许我们添加一个新的操作，而不会破坏现有代码结构。我们可以定义一个DocumentVisitor，它可以访问文档的每一个元素，并根据元素的类型执行相应的格式化操作。这样，当需要新的格式化功能时，只需要添加一个新的访问者即可，无需修改现有文档元素的类。

    👩‍💻 举例来说，导出为PDF或HTML的功能就可以通过实现不同的访问者来完成，每个访问者针对不同元素实现具体的导出逻辑。
  • 编译器设计中的代码优化 🖥️🚀：
    编译器在编译源代码时，会生成一个抽象语法树（AST）。代码优化是编译过程中的一个重要步骤，可能需要基于AST执行复杂的操作，比如常量折叠、死代码删除等。

    在这里，访问者模式同样适用。我们可以定义一个OptimizationVisitor访问者，它遍历AST，并应用不同的优化技术。由于AST的结构相对稳定，应用访问者模式可以在不修改AST节点定义的情况下，轻松添加新的优化技术或者改变现有技术。

    📊 例如，为了提升执行效能，一个性能优化访问者可以遍历AST，在不影响程序语义的前提下修改或简化某些节点。

    下面我们来实现文档编辑器的格式化操作 📄✏️。

1.2 一坨坨代码实现😻

在这里插入图片描述
    用一坨坨代码来实现，可以通过面向对象的继承和多态性来实现这个场景。下面是一个简化的Java实现示例：

  1. 首先，我们定义一个抽象的TextElement类，它包含一些公共的行为和属性，比如添加样式和导出功能。然后，我们为每种具体的文本元素（段落、图片、表格）创建子类，并实现特定的行为。
// 抽象类 TextElement 表示文档中的文本元素  
public abstract class TextElement {  
    // 添加样式的抽象方法  
    public abstract void addStyle(String style);  
      
    // 导出为特定格式的抽象方法  
    public abstract String exportTo(String format);  
}
  1. Paragraph 类表示段落元素，继承自 TextElement ：
// 段落类  
public class Paragraph extends TextElement {  
    private String text;  
      
    public Paragraph(String text) {  
        this.text = text;  
    }  
      
    @Override  
    public void addStyle(String style) {  
        // 实现段落的样式添加逻辑  
        System.out.println("Added style " + style + " to paragraph.");  
    }  
      
    @Override  
    public String exportTo(String format) {  
        // 实现段落的导出逻辑  
        if ("html".equals(format)) {  
            return "<p>" + text + "</p>";  
        } else if ("pdf".equals(format)) {  
            // 这里简化处理，实际导出PDF会更复杂  
            return "Paragraph text for PDF: " + text;  
        }  
        return "Unsupported format";  
    }  
}
  1. Image 类表示图片元素，继承自 TextElement
public class Image extends TextElement {  
    private String url;  
      
    public Image(String url) {  
        this.url = url;  
    }  
      
    @Override  
    public void addStyle(String style) {  
        // 图片可能不支持样式，或者支持有限的样式  
        System.out.println("Added style (if applicable) " + style + " to image.");  
    }  
      
    @Override  
    public String exportTo(String format) {  
        // 实现图片的导出逻辑  
        if ("html".equals(format)) {  
            return "<img src=\"" + url + "\" />";  
        } else if ("pdf".equals(format)) {  
            // 简化处理  
            return "Image URL for PDF: " + url;  
        }  
        return "Unsupported format";  
    }  
}

类似地，可以创建 Table 类等其他文本元素的子类…
4. DocumentEditor 类表示文档编辑器，包含一组文本元素，并提供格式化和导出功能

public class DocumentEditor {  
    private List<TextElement> elements = new ArrayList<>();  
      
    public void addElement(TextElement element) {  
        elements.add(element);  
    }  
      
    public void addStyleToAll(String style) {  
        for (TextElement element : elements) {  
            element.addStyle(style);  
        }  
    }  
      
    public String exportDocumentTo(String format) {  
        StringBuilder sb = new StringBuilder();  
        for (TextElement element : elements) {  
            sb.append(element.exportTo(format));  
        }  
        return sb.toString();  
    }  
}

    在这个实现中，我们避免了使用设计模式，而是直接利用了Java的面向对象特性。每个文本元素都是一个TextElement的子类，并且实现了自己的样式添加和导出逻辑。DocumentEditor类负责管理这些元素，并提供对整个文档进行样式添加和导出的功能。

    虽然上述实现没有使用设计模式，但也体现出了如下优点：

  1. 结构简单直观：
    代码的结构相对简单，易于理解。每个类都有明确的职责，例如TextElement定义了文本元素的基本行为，而Paragraph和Image等子类则实现了具体的行为。
  2. 易于实现和调试：
    由于没有使用复杂的设计模式或大量的接口和抽象类，因此代码相对容易实现和调试。这对于小型项目或原型开发可能是有利的。
  3. 直接操作文本元素：
    DocumentEditor类可以直接操作TextElement对象，这提供了对文档元素的直接和细粒度的控制。这可能在某些情况下是有益的，特别是当需要精确控制文档的格式和内容时。
  4. 易于扩展新的文本元素类型：
    尽管可能需要在DocumentEditor中添加对新类型的支持，但添加新的文本元素类型相对简单。只需创建一个新的TextElement子类并实现必要的方法即可。

1.3 痛点

在这里插入图片描述

    然而，没有复杂的设计下体现上述优点的同时也伴随着一些潜在的缺点，比如代码的可维护性、灵活性和可扩展性可能会受到限制。对于更大或更复杂的项目，可能需要考虑使用设计模式和其他高级技术来改善代码的结构和质量。

    缺点（问题）下面逐一分析：

  1. 可扩展性问题：🤯
    如果需要支持新的文本元素类型或新的编辑功能，可能需要修改现有的类和方法，这违反了面向对象设计中的开闭原则。理想情况下，设计应该允许通过添加新代码而不是修改现有代码来扩展功能。
  2. 硬编码和灵活性问题：🤯
    如果某些功能（如导出格式或样式）是硬编码在类中的，那么添加或修改这些功能将需要直接修改类的代码。这会降低系统的灵活性和可配置性。
  3. 缺乏抽象层：🤯
    没有使用接口或抽象类来定义共同的行为和属性，这可能导致子类之间的不一致性和重复代码。引入抽象层可以提高代码的复用性和可维护性。
  4. 用户体验和交互性：🤯
    如果实现没有考虑用户体验和交互性，如实时预览、撤销/重做功能或友好的用户界面，那么它可能不适合作为实际的文档编辑软件使用。
  5. 性能和效率问题：🤯
    对于大型文档或复杂的编辑操作，如果实现没有优化性能和资源使用，可能会导致软件运行缓慢或出现崩溃等问题。

    违反的设计原则（问题）下面逐一分析：

  1. 🛠️单一职责原则（Single Responsibility Principle, SRP）：
    TextElement 类可能违反了单一职责原则，因为它同时负责样式添加和导出功能。这意味着如果需要修改样式添加或导出的逻辑，可能会影响到TextElement类的其他部分。
    DocumentEditor 类也可能违反了这一原则，因为它既负责管理文本元素，又负责样式添加和文档导出。

  2. 🛠️开闭原则（Open/Closed Principle, OCP）：
    正如之前提到的，如果需要添加新的文本元素类型或新的导出格式，可能需要修改现有的TextElement子类或exportTo方法。这违反了开闭原则，即对扩展开放，对修改封闭。

  3. 🛠️里氏替换原则（Liskov Substitution Principle, LSP）：
    在这个实现中，没有明显的违反里氏替换原则的情况，因为所有的子类（如Paragraph和Image）都可以替换它们的基类TextElement而不影响程序的正确性。但是，如果某些子类不支持特定的样式或导出格式，而基类的方法假设所有子类都支持，这可能会在未来导致问题。

  4. 🛠️接口隔离原则（Interface Segregation Principle, ISP）：
    由于没有使用接口来定义行为，这个原则在这里不太适用。但是，如果我们把TextElement看作是一个接口（尽管它是一个抽象类），那么它可能违反了接口隔离原则，因为它包含了添加样式和导出两种不相关的行为。

  5. 🛠️依赖倒置原则（Dependency Inversion Principle, DIP）：
    在这个实现中，高层模块（如DocumentEditor）依赖于低层模块（如具体的TextElement子类），而不是依赖于抽象。这意味着如果添加新的文本元素类型，可能需要修改DocumentEditor类来适应新的类型。这违反了依赖倒置原则，即高层模块不应该依赖于低层模块，它们都应该依赖于抽象。

  6. 🛠️迪米特法则（Law of Demeter, LoD）或最少知识原则（Least Knowledge Principle, LKP）：
    DocumentEditor类直接与TextElement及其子类交互，这可能违反了迪米特法则，因为它可能知道太多关于这些类的内部细节。理想情况下，DocumentEditor应该只通过TextElement的公共接口与之交互。

二、解决方案

在这里插入图片描述

    为了改善上述的实现设计，考虑引入接口来定义行为，使用设计模式（如访问者模式）来分离操作和数据结构，以及遵循上述设计原则来组织代码。这样可以提高代码的可维护性、可扩展性和灵活性。

2.1 定义

访问者模式（Visitor Pattern）是一种行为设计模式，它允许你在不改变各类的前提下定义新的操作，即在不修改已存在的类的结构的情况下增加新的操作。

2.2 案例分析🧐

    分析关键因素
    是否适合使用访问者模式的场景中，我们可以考虑以下几个关键因素：

  1. 结构稳定性与操作多变性：
    如果数据结构相对稳定，而作用于结构上的操作易于变化，那么访问者模式可能是一个好选择。在本例中，文档编辑器支持的文本元素类型（段落、图片、表格等）构成了相对稳定的数据结构，而对这些元素进行的格式化、样式调整或导出等操作则可能随着用户需求或软件升级而变化。
  2. 多种类型的元素：
    当系统中有多种类型的对象，并且需要对这些不同类型的对象执行不同的操作时，访问者模式可以帮助我们清晰地组织代码。在文档编辑器中，不同类型的文本元素（如段落、图片、表格）需要不同的处理逻辑，这符合访问者模式的应用场景。
  3. 行为的添加与元素的无关性：
    如果在不修改现有类的情况下需要添加新的操作，访问者模式允许我们通过添加新的访问者类来实现这一点，而无需更改元素类。在文档编辑器的例子中，这意味着我们可以在不修改段落、图片、表格等类的情况下，添加新的格式化选项或导出格式。
  4. 操作的解耦：
    访问者模式有助于将操作与对象结构解耦。这意味着我们可以独立地改变对象的结构和在这些对象上定义的操作。在文档编辑器的上下文中，这意味着文本元素的内部结构和表示可以与执行在这些元素上的操作（如格式化或导出）分开变化。
  5. 清晰的职责划分：
    访问者模式允许我们将算法（即访问者的方法）与对象结构分离开来。这使得代码更加模块化，每个部分都有清晰的职责。在文档编辑器的场景中，访问者负责执行特定的操作（如添加样式或导出），而元素类则负责提供接受访问者的接口。

    当我们识别到一个系统中存在多种类型的对象、需要对这些对象执行多种不同的操作、并且希望在不修改对象类的情况下添加新的操作时，就可以考虑使用访问者模式。在文档编辑器的场景中，这些条件都得到了满足，因此访问者模式是一个合适的设计选择。

    分析适用原因
    在这个复杂的文档编辑器场景中，访问者模式非常适用，原因主要有以下几点：

  1. 多种类型的文本元素：
    文档编辑器支持段落、图片、表格等多种文本元素，每种元素可能需要不同的处理方式。访问者模式允许我们定义多个访问者类，每个类专门处理一种类型的元素，从而实现操作的分离和专业化。

  2. 操作易于变化：
    对文档进行格式化、样式调整或导出为不同格式时，操作可能会随着用户需求的变化而频繁更改。访问者模式通过将操作逻辑封装在独立的访问者类中，使得这些变化可以独立于文档结构进行，从而降低了代码的耦合性，提高了系统的可维护性。

  3. 不改变元素类：
    访问者模式允许我们在不修改现有元素类的情况下增加新的操作。这意味着当需要添加新的格式化选项或导出格式时，我们不需要改动段落、图片、表格等类的代码，只需创建新的访问者类即可。这符合开闭原则，即对扩展开放，对修改封闭。

  4. 单一职责原则：
    每个访问者类只负责一种特定的操作，比如添加样式或导出为特定格式。这使得代码更加清晰、易于理解和维护。同时，这也便于团队成员之间的分工协作，不同的人员可以专注于不同的访问者实现。

  5. 灵活性：
    访问者模式提供了很大的灵活性，允许我们在运行时动态地改变元素的操作行为。例如，我们可以根据用户的选择来切换不同的访问者，以实现不同的格式化或导出效果。

    访问者模式在处理多种类型文本元素且操作易于变化的场景中具有显著优势。在文档编辑器的例子中，通过定义适当的访问者和元素接口，我们可以实现一个可扩展、可维护且高度灵活的系统。

2.3 访问者模式结构图及说明

在这里插入图片描述

主要组件：

  1. 访问者接口（Visitor Interface）：
    - 定义了对每一个具体元素类（ConcreteElement）的访问操作。
    - 通常包含多个visit方法，每个方法对应一个具体元素类。

  2. 具体访问者（Concrete Visitor）：
    - 实现了访问者接口，并为每一种具体元素类提供了相应的访问操作。
    - 包含了对各种元素执行具体操作的业务逻辑。

  3. 抽象元素（Element）：
    - 定义了一个accept方法，用于接受访问者对象。
    - 该方法通常接受一个访问者接口类型的参数。

  4. 具体元素（Concrete Element）：、
    - 实现了元素接口，并提供了accept方法的具体实现。
    - 在accept方法中调用访问者对象的对应visit方法。

  5. 对象结构（Object Structure）：
    - 是一个元素的集合，如列表、组合结构等。
    - 可以遍历其包含的元素，并调用它们的accept方法以接受访问者。

  6. 客户端（Client）：
    - 创建访问者对象，并将其传递给对象结构中的元素进行访问。
    - 负责控制访问过程的开始和结束。

交互和通信过程：

  1. 初始化阶段：
    - 客户端创建访问者对象。
    - 客户端获取或创建对象结构，并向其添加元素对象。

  2. 客户端调用对象结构的方法：
    -客户端调用对象结构中的方法（例如visitAll），该方法负责遍历所有的接受者对象。

  3. 访问阶段：
    对象结构遍历其所包含的所有接受者对象，对每个接受者对象执行以下步骤。
        -对象结构依次遍历其内部的元素，对于每个元素：
            -元素对象调用其accept方法，并传入访问者对象。

  4. 接受者调用访问者的方法：
    对于每个接受者对象，对象结构调用其accept方法，并将访问者对象
        - 访问者对象根据元素的具体类型调用相应的visit方法。作为参数传入。
        - visit方法内，访问者可以对元素执行特定的操作。

  5. 完成阶段：
    - 一旦所有元素都被访问过，访问过程结束。

  6. 接受者对象与访问者交互：
    在accept方法中，接受者对象调用访问者对象的相应方法（例如visitElement），并将自己作为参数传入。
        - 客户端可以销毁或重用访问者和对象结构。

  7. 访问者执行操作：
    访问者在被调用的方法中执行针对接受者对象的操作。

2.4 使用访问者模式重构示例

    要使用访问者模式重构上述场景，我们首先需要定义一个访问者接口，用于表示可以对文本元素执行的操作。然后，我们为每个具体的操作创建访问者实现。此外，我们还需要在文本元素类层次结构中引入一个接受访问者的方法。
    下面是一个使用访问者模式实现的文档编辑器的格式化操作 📄✏️的示例：

  1. 访问者接口
public interface TextElementVisitor {  
    void visit(Paragraph paragraph);  
    void visit(Image image);  
    // 可以添加更多的visit方法以处理其他类型的TextElement  
}
  1. 具体的访问者实现：导出文档
public class ExporterVisitor implements TextElementVisitor {  
    private StringBuilder export;  
  
    public ExporterVisitor() {  
        this.export = new StringBuilder();  
    }  
  
    public void visit(Paragraph paragraph) {  
        export.append("<p>").append(paragraph.getText()).append("</p>\n");  
    }  
  
    public void visit(Image image) {  
        export.append("<img src=\"").append(image.getSource()).append("\" />\n");  
    }  
  
    public String getExport() {  
        return export.toString();  
    }  
}
  1. 具体的访问者实现：添加样式（这里仅作示例，实际中可能需要更复杂的实现）
public class StylerVisitor implements TextElementVisitor {  
    private String style;  
  
    public StylerVisitor(String style) {  
        this.style = style;  
    }  
  
    public void visit(Paragraph paragraph) {  
        paragraph.setStyle(style);  
    }  
  
    // 假设Image不支持设置样式，因此不实现该方法  
    public void visit(Image image) {  
        // Do nothing or throw an UnsupportedOperationException  
    }  
}
  1. 文本元素抽象类
public abstract class TextElement {  
    public abstract void accept(TextElementVisitor visitor);  
    // 其他公共方法和属性  
}
  1. 具体的文本元素：段落
public class Paragraph extends TextElement {  
    private String text;  
    private String style; // 可以添加更多属性和方法  
  
    public Paragraph(String text) {  
        this.text = text;  
    }  
  
    public void setStyle(String style) {  
        this.style = style;  
    }  
  
    public String getText() {  
        return text;  
    }  
  
    public void accept(TextElementVisitor visitor) {  
        visitor.visit(this);  
    }  
}
  1. 具体的文本元素：图片
public class Image extends TextElement {  
    private String source; // 可以添加更多属性和方法  
  
    public Image(String source) {  
        this.source = source;  
    }  
  
    public String getSource() {  
        return source;  
    }  
  
    public void accept(TextElementVisitor visitor) {  
        visitor.visit(this);  
    }  
}
  1. 文档编辑器类，使用访问者模式来处理文本元素
public class DocumentEditor {  
    private List<TextElement> elements = new ArrayList<>();  
  
    public void addElement(TextElement element) {  
        elements.add(element);  
    }  
  
    public void acceptVisitor(TextElementVisitor visitor) {  
        for (TextElement element : elements) {  
            element.accept(visitor);  
        }  
    }  
}
  1. 客户端代码示例
public class ClientCode {  
    public static void main(String[] args) {  
        DocumentEditor editor = new DocumentEditor();  
        editor.addElement(new Paragraph("Hello, World!"));  
        editor.addElement(new Image("path/to/image.jpg"));  
  
        // 使用ExporterVisitor导出文档  
        ExporterVisitor exporter = new ExporterVisitor();  
        editor.acceptVisitor(exporter);  
        System.out.println(exporter.getExport());  
  
        // 使用StylerVisitor为段落添加样式（注意：这个示例中Image不支持样式）  
        StylerVisitor styler = new StylerVisitor("bold");  
        editor.acceptVisitor(styler);  
        // 这里需要额外的逻辑来验证或处理样式是否已正确应用  
    }  
}

    在这个重构后的示例中，我们定义了一个TextElementVisitor接口，并为导出和添加样式创建了两个具体的访问者实现。文本元素类现在有一个accept方法，它接受一个访问者并调用访问者的相应visit方法。DocumentEditor类使用acceptVisitor方法来应用访问者到其包含的文本元素上。

    这种方式的好处是，我们可以很容易地添加新的访问者来实现新的操作，而无需修改现有的文本元素类。这提高了代码的可扩展性和可维护性。同时，每个访问者都可以专注于自己的职责，实现了单一职责原则。

2.5 重构后解决的问题

在这里插入图片描述

  优点
    使用访问者模式重构后可以有效地解决 1.3 痛点 中提到的一些缺点。通过引入访问者设计模式解决了若干设计原则的应用问题，具体体现在以下几个方面：

  1. 开闭原则（Open-Closed Principle）：
    在不修改现有类（如Paragraph和Image）的前提下，访问者模式允许我们添加新的操作（即新的访问者类，如ExporterVisitor和StylerVisitor）。这意味着现有的文本元素类对修改是封闭的，但对新添加的功能是开放的。
  2. 单一职责原则（Single Responsibility Principle）：
    每个访问者类（如ExporterVisitor和StylerVisitor）都专注于一个特定的职责，如导出文档或添加样式。这避免了将多个不相关的操作混杂在同一个类中，提高了代码的可读性和可维护性。
  3. 依赖倒置原则（Dependency Inversion Principle）：
    在访问者模式中，高层模块（如DocumentEditor）不依赖于低层模块的具体实现（如具体的TextElement子类），而是依赖于抽象（如TextElementVisitor接口和TextElement抽象类）。这减少了类之间的耦合度，使得系统更加灵活和可扩展。
  4. 里氏替换原则（Liskov Substitution Principle）：
    在访问者模式中，子类（如Paragraph和Image）可以扩展父类（如TextElement）的行为，并且客户端代码（如DocumentEditor）在无需知道具体子类类型的情况下，通过调用父类的方法（如accept）来与子类交互。这确保了子类能够替换父类而不会出现行为上的异常。

    然而，值得注意的是，访问者模式并非没有缺点。它可能违反迪米特法则（Law of Demeter），因为具体元素类（如Paragraph和Image）需要了解并直接调用访问者的方法，这增加了它们之间的耦合度。此外，如果频繁添加新的文本元素类型或新的操作，访问者模式可能会导致类的数量迅速增加，从而增加系统的复杂性。

    总的来说，访问者模式在上述实现中通过引入抽象访问者和具体访问者类来分离操作和对象结构，从而提高了代码的可扩展性、可维护性和可读性。这符合开闭原则、单一职责原则和依赖倒置原则等面向对象设计原则的要求。如下更多优点：

  1. 扩展性好：
    访问者模式允许在不修改现有类的情况下添加新的操作。在上述实现中，如果我们需要添加新的文本处理功能（比如一个新的访问者用于检查拼写错误），我们只需要创建一个新的访问者类并实现相应的方法，而不需要修改现有的Paragraph和Image类。这符合开闭原则，即对扩展开放，对修改封闭。
  2. 复用性好：
    访问者模式通过定义通用的功能接口，提高了系统的复用程度。在上述实现中，TextElementVisitor接口定义了所有访问者都应该实现的方法，而具体的访问者类（如ExporterVisitor和StylerVisitor）则提供了这些方法的具体实现。这意味着我们可以轻松地复用这些访问者类来处理不同类型的文本元素。
  3. 灵活性好：
    访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可以相对自由地演化而不影响系统的数据结构。在上述实现中，文本元素类（如Paragraph和Image）与访问者类之间的关联是通过接口而不是具体实现来定义的，这增加了系统的灵活性。

  缺点
上述实现虽然有许多优点，但也存在一些潜在的缺点，这些缺点通常与访问者设计模式的特性和使用场景相关：

  1. 破坏封装性：
    访问者模式要求访问者能够访问并调用对象的内部操作或状态，这可能会破坏对象的封装性。在上述实现中，具体元素类（如Paragraph和Image）需要向访问者暴露一些内部细节，以便访问者能够正确地处理它们。这可能会导致对象的内部状态被外部类不恰当地访问或修改。
  2. 违反依赖倒置原则：
    访问者模式有时可能会违反依赖倒置原则，因为它可能使高层模块依赖于低层模块的具体实现而不是抽象。在上述实现中，如果存在对具体访问者类的直接依赖，而不是依赖于抽象访问者接口，就可能出现这种情况。然而，这可以通过始终使用抽象接口来避免。
  3. 具体元素变更困难：
    当系统中的具体元素类需要变更时（如添加新的属性或方法），访问者模式可能会带来一些挑战。因为每个访问者类都可能需要相应地更新以处理这些变更。在上述实现中，如果Paragraph或Image类发生了变化，所有相关的访问者类都可能需要进行修改。
  4. 类数量增加：
    访问者模式可能会导致系统中类的数量显著增加。每个新的操作或功能都可能需要一个新的访问者类来实现。在上述实现中，随着功能的增加，可能会看到越来越多的访问者类被创建。
  5. 不适用于频繁变化的对象结构：
    如果对象结构经常发生变化（例如添加或删除新的元素类），则访问者模式可能不是最佳选择。因为每次添加新的元素类时，都需要在所有访问者类中添加相应的处理逻辑。在上述实现中，如果文本元素类型经常变化，那么维护访问者类将变得非常困难。

 
 
    注：本文只转载部分内容，三连 或 更多请跳转原文。

要快乐_
关注
  • 45
    点赞
  • 踩
  • 40
    收藏
    觉得还不错? 一键收藏
  • 18
    评论
专栏目录
揭开计算机的神秘面纱--计算机系统.pptx
05-17
任务1 揭开计算机的神秘面纱 子任务2 计算机系统 任务提出 随着时代的不断发展，计算机成为了我们工作、学习和生活中离不开的朋友。下面就跟随我来了解一下计算机系统的组成吧！ 计算机系统组成 计算机硬件系统 ...
探索设计模式的魅力：揭开访问者模式的神秘面纱-轻松增强对象行为
制定明确可量化的目标，坚持默默的做事。
02-27 4224
访问者模式是一种重要的软件设计模式，其核心思想是将操作逻辑与数据结构分离，通过引入访问者类实现对数据结构中元素的灵活操作。这种模式特别适用于处理具有复杂行为和数据结构的对象，如编译器和图形编辑器等。访问者模式不仅可以提高系统的灵活性和可扩展性，还有助于增强代码的可读性和可维护性，降低模块间的耦合度。对于软件架构师和开发人员来说，熟练掌握访问者模式具有重要的实践意义，能够帮助他们更有效地设计和开发软件系统，实现更好的系统结构和代码组织。
探索设计模式的魅力：顺畅的职责传递-用责任链模式优化决策流程
制定明确可量化的目标，坚持默默的做事。
02-22 4610
本文首先通过经典场景展示了不使用设计模式时的问题与痛点。接着，引入责任链模式，详细讲解了其定义、解决问题的方式、结构图及工作原理，并通过重构示例展示了该模式如何解决原有痛点。最后，对责任链模式的优势、缺点以及在实际应用中可能遇到的挑战和限制进行了总结。责任链模式通过解耦请求发送者和接收者，提供了灵活的请求处理机制，适用于多个处理者按顺序处理请求的场景。然而，该模式也可能导致请求得不到处理或性能下降等问题，需在实际应用中权衡利弊。
深入Linux进程内核：揭开进程工作原理的神秘面纱
探索C++编程的奥秘，分享深入的技术见解和实践，旨在激发读者创造力与解决问题的思维。
04-22 152
深入Linux进程内核：揭开进程工作原理的神秘面纱
Java 全栈知识体系（ PDF 可下载）
m0_67698950的博客
03-17 5119
40000 +字长文总结，民工哥已将此文整理成PDF文档了，需要的见文后下载获取方式。 全栈知识体系总览 Java入门与进阶 面向对象与Java基础 Java 基础 - 面向对象 Java 基础 - 知识点 Java 基础 - 图谱 & Q/A 基础知识点复习完了以后，我们需要深入的理解Java中的一些基础机制： Java 基础 - 泛型机制详解 Java泛型这个特性是从JDK 1.5才开始加入的，因此为了兼容之前的版本
《设计模式解析（第2版•修订版）》目录—导读
weixin_33856370的博客
05-02 184
作者简介设计模式解析（第2版•修订版）Alan Shalloway 美国Net Objectives咨询/培训公司的创始人和CEO。他是麻省理工学院的计算机科学硕士，具有30多年面向对象咨询、培训和软件开发的经验，并经常受邀在重要的软件开发会议（包括SD Expro、Java One、OOP和OOPSLA）上演讲。James R. Trott 美...
牛逼！Java 从入门到精通，超全汇总版
热门推荐
程序员cxuan的个人主页
05-06 7万+
文章目录Java 基础Head First JavaJava 核心技术卷一Java 编程思想设计模式Head First 设计模式图解设计模式设计模式重学 Java 设计模式Java 进阶Java 并发编程实战Java 并发编程艺术Java 并发编程之美图解Java多线程设计模式JVM深入理解 Java 虚拟机Java 虚拟机规范HotSpot 实战自己动手写 Java 虚拟机MySQLMySQL 基础教程SQL 基础教程深入浅出 MySQLMySQL 必知必会SQL 必知必会高性能 MySQLMySQL
Python开发【Part 12】：协程与IO操作模式
weixin_30951389的博客
02-25 56
本节内容 Python协程 Select\Poll\Epoll异步IO与事件驱动 IO多路复用 一、Python协程 　　协程，又称微线程，纤程。英文名Coroutine。一句话说明什么是线程：协程是一种用户态的轻量级线程。 　　协程拥有自己的寄存器上下文和栈。协程调度切换时，将寄存器上下文和栈保存到其他地方，在切回来的时候，恢复先前保存的寄存器上下文和栈。因此： ...
【论文阅读】DRIVEGPT4: INTERPRETABLE END-TO-END AUTONOMOUS DRIVING VIA LARGE LANGUAGE MODEL
技术宅学长的博客
11-02 362
在过去的十年里，自动驾驶在学术界和工业界都得到了快速发展。然而，其有限的可解释性仍然是一个重要的未解决问题，严重阻碍了自动驾驶汽车的商业化和进一步发展。以前使用小型语言模型的方法由于缺乏灵活性、泛化能力和鲁棒性而未能解决这个问题。最近，多模态大语言模型(llm)因其通过文本处理和推理非文本数据(如图像和视频)的能力而受到了研究界的广泛关注。在本文中，我们提出了DriveGPT4，一个利用llm的可解释的端到端自动驾驶系统。
Billy Belceb病毒编写教程---Win32篇
hacker150的专栏
04-01 1619
正在处理中，请稍后…… Billy Belceb病毒编写教程---Win32篇                                     翻译:onlyu                             【译者声明】~~~~~~~~~~~     这是一篇关于病毒基础知识的教程，作者Billy Belceb，西班牙
揭开计算机的神秘面纱--认识计算机.pptx
05-17
任务提出;计算机的诞生及发展历史 计算机的特点 计算机的应用 计算机的分类;;计算机的发展;★计算机的问世 第一台计算机ENIAC（埃尼阿克） 1943年~1946年美国宾夕法尼亚大学研制。...ENIAC共有18000多个电子管，1500个...
揭开极端编程的神秘面纱：结对致胜
03-05
某些XP实践让项目经理感到可笑，而让程序员畏缩。结对编程（或结对）就是其中一种。根据一些XP评论家的反馈，结对编程获得了“最可能令人不快的方法”的“奖项”—也就是说，如果您不得不给它一个头衔的话。...
Epoll:epoll内核源码详解剖析，揭开epoll的神秘面纱-源码解析
03-24
epoll内核源码详解剖析，揭开epoll的神秘面纱 为什么要剖析epoll原始码 在学习网络编程的过程中，在使用epoll的时候感觉epoll就像是神秘的魔法一样，可以创建百万的套接字句柄和以O（1）的时间复杂度返回允许的事件...
设计模式：桥接模式
玉汝于成
05-06 859
接模式是一种对象结构型模式，它将抽象部分与它的实现部分分离，使它们都可以独立地变化。这种分离允许抽象和实现部分独立地扩展，而不会相互影响。桥接模式基于类的最小设计原则，通过封装、聚合及继承等行为让不同的类承担不同的职责。
设计模式: 工厂模式
m0_59925573的博客
05-02 788
定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。主要解决接口选择的问题。我们明确地计划不同条件下创建不同实例时。让其子类实现工厂接口，返回的也是一个抽象的产品。创建过程在其子类执行。1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。2、在 Hibernate 中，如果需要更换数据库，工厂模式同样发挥了作用。只需简单地更改方言（Dialect）和数据库驱动（Driver），就能够实现对不同数据库的切换。
设计模式之MVC模式
Rcain_R的博客
05-02 1334
MVC（Model-View-Controller）模式是一种软件设计模式，广泛应用于构建用户界面的软件架构中，特别是在Web应用程序开发中。
设计模式一
hummhumm的专栏
05-04 846
单例模式简介。
java设计模式 桥接
最新发布
hummhumm的专栏
05-07 748
**前端框架的组件库**：在许多前端UI框架中，如Bootstrap或Ant Design，桥接模式被用于实现组件样式（如主题颜色、尺寸等）与组件功能的分离。- **ORM框架**：在对象关系映射(ORM)框架中，如Hibernate或MyBatis，桥接模式用于连接面向对象的领域模型与关系型数据库的SQL查询，使得开发者可以在不修改数据库访问逻辑的情况下，更换或升级数据库。1. **分离抽象**：桥接模式的核心在于将抽象部分（如形状的逻辑）与它的实现部分（如颜色的具体表现）分离。
揭开一个公式(snr=6.02n+1.76db)的神秘面纱,以及为什么我们要予以关注
05-02
这个公式的神秘面纱在于它给出了一个具体的计算方式，它能够让我们快速、准确地计算信噪比和采样精度之间的关系。这种关系对于数字信号处理非常重要，因为它直接影响到我们对信号的理解和分析。 在数字信号处理领域...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 18
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值