替代访客模式？ [英] Alternative to the visitor pattern?

问题描述

我正在寻找访问者模式的替代方案。让我专注于模式的几个相关方面，同时忽略不重要的细节。我将使用Shape示例（对不起！）：

I am looking for an alternative to the visitor pattern. Let me just focus on a couple of pertinent aspects of the pattern, while skipping over unimportant details. I'll use a Shape example (sorry!):

1. 您有一个实现IShape界面的对象层次结构


2. 您将在层次结构中的所有对象上执行多个全局操作，例如Draw，WriteToXml等...


3. 直接跳入并将Draw（）和WriteToXml（）方法添加到IShape界面是很诱人的。这不一定是一件好事 - 每当您希望添加要在所有形状上执行的新操作时，每个IShape派生类必须更改。


4. 为每个操作实施访问者即Draw访问者或WirteToXml访问者将该操作的所有代码封装在一个类中。然后添加一个新的操作就是创建一个新的访问者类，对所有类型的IShape执行操作


5. 当你需要添加一个新的IShape派生类时，你基本上有同样的问题，你在3 - 所有的访客类必须改变添加一个方法来处理新的IShape派生类型

1. You have a hierarchy of objects that implement the IShape interface
2. You have a number of global operations that are to be performed on all objects in the hierarchy, e.g. Draw, WriteToXml etc...
3. It is tempting to dive straight in and add a Draw() and WriteToXml() method to the IShape interface. This is not necessarily a good thing - whenever you wish to add a new operation that is to be performed on all shapes, each IShape-derived class must be changed
4. Implementing a visitor for each operation i.e. a Draw visitor or a WirteToXml visitor encapsulates all the code for that operation in one class. Adding a new operation is then a matter of creating a new visitor class that performs the operation on all types of IShape
5. When you need to add a new IShape-derived class, you essentially have the same problem as you did in 3 - all visitor classes must be changed to add a method to handle the new IShape-derived type

阅读关于访客模式状态的地方，5点几乎是模式工作的主要标准，我完全同意。如果IShape派生类的数量是固定的，那么这可以是一个非常优雅的方法。

Most places where you read about the visitor pattern state that point 5 is pretty much the main criteria for the pattern to work and I totally agree. If the number of IShape-derived classes is fixed, then this can be a quite elegant approach.

所以，问题是当添加一个新的IShape派生类时 - 每个访问者实现都需要添加一个新的方法来处理该类。这是最好的，令人不快，最坏的情况是不可能，并表明这种模式并不是真正的设计来应对这种变化。

So, the problem is when a new IShape-derived class is added - each visitor implementation needs to add a new method to handle that class. This is, at best, unpleasant and, at worst, not possible and shows that this pattern is not really designed to cope with such changes.

所以，问题是任何人都会遇到处理这种情况的替代方法？

So, the question is has anybody come across alterative approaches to handling this situation?

推荐答案

你可能想看看策略模式。这仍然可以让您分心，同时仍然可以添加新功能，而无需更改层次结构中的每个类。

You might want to have a look at the Strategy pattern. This still gives you a separation of concerns while still being able to add new functionality without having to change each class in your hierarchy.

class AbstractShape
{
    IXmlWriter _xmlWriter = null;
    IShapeDrawer _shapeDrawer = null;

    public AbstractShape(IXmlWriter xmlWriter, 
                IShapeDrawer drawer)
    {
        _xmlWriter = xmlWriter;
        _shapeDrawer = drawer;
    }

    //...
    public void WriteToXml(IStream stream)
    {
        _xmlWriter.Write(this, stream);

    }

    public void Draw()
    {
        _drawer.Draw(this);
    }

    // any operation could easily be injected and executed 
    // on this object at run-time
    public void Execute(IGeneralStrategy generalOperation)
    {
        generalOperation.Execute(this);
    }
}

更多信息在这个相关的讨论中：

More information is in this related discussion:

如果一个对象将自己写入文件，或者另一个对象是否会对其执行I / O操作？

这篇关于替代访客模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！