Java 访问者模式扩展功能

发布于 2024-12-18 21:45:01 字数 748 浏览 1 评论 0原文

我正在研究访问者模式并遇到了这个有用的示例: https://stackoverflow.com/a/2604798/974594 。这篇文章非常清晰,很容易理解,尽管如此,我在理解最后一部分时遇到了问题,从这里开始:

话虽如此,访问者通常都是矫枉过正,他们有一个 API 的趋势非常复杂,并且可能会非常麻烦 为每种新行为定义一个新访问者。

通常,应该使用继承等更简单的模式来代替 访客。例如,原则上我可以编写一个类:

类 FruitPricer : IFruitVisitor
{
    公共双价格 { 得到;私人套装; }
    public void Visit(橙子水果) { 价格 = 0.69; }
    public void Visit(苹果水果) { 价格 = 0.89; }
    public void Visit(香蕉水果) { Price = 1.11; }
}

它可以工作,但是比这个简单的修改有什么优势:

抽象类Fruit

<前><代码>{ 公共抽象无效接受(IFruitVisitor 访客); 公共抽象双价格 { 得到; } }

我不明白他在这里说什么。我的意思是,如果他现在想要实现“价格”功能,则必须在现有代码中更改/添加哪些内容(基于此模式方法)?=

I was studying the visitor pattern and came across this useful example: https://stackoverflow.com/a/2604798/974594. The post is very clear and very easy to understand, altought, i'm having problems understanding the last part, starting here:

With that said, visitors are usually overkill, and they have a
tendency grossly complicate APIs, and it can be very cumbersome to
define a new visitor for every new kind of behavior.

Usually, simpler patterns like inheritance should be used in place of
visitors. For example, in principle I could write a class like:

class FruitPricer : IFruitVisitor
{
    public double Price { get; private set; }
    public void Visit(Orange fruit) { Price = 0.69; }
    public void Visit(Apple fruit) { Price = 0.89; }
    public void Visit(Banana fruit) { Price = 1.11; }
}

It works, but what's the advantage over this trivial modification:

abstract class Fruit

{
    public abstract void Accept(IFruitVisitor visitor);
    public abstract double Price { get; }
}

I'm not getting what is he saying here. I mean, if he now want to implement the feature 'price', what must be changed/added to the existing code (based on this pattern approach)?=

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

不羁少年 2024-12-25 21:45:01

您引用的答案忽略了访客的大部分要点。它说“访问者用于在不牺牲类型安全的情况下实现类型测试”,这是完全错误的。 GOF 书中说“访问者可以让你定义一个新的操作,而无需更改它所操作的元素的类”。访问者当然可以用于测试类型以外的对象,以及对不涉及测试的对象执行操作。

人们经常说“Visitor 杀伤力太大”,但通常是人们试图将 Visitor 用于其不该做的事情,然后发现(令人惊讶)它实际上并不起作用。

发帖者是正确的,他们引用的第二段代码是实现该功能的更简单的方法,但它忽略了当您不想修改 Fruit 类时使用 Visitor 的要点。

The answer you reference misses much of the point of Visitor. It says "visitors are used to implement type-testing without sacrificing type-safety", which is simply incorrect. The GOF book says "visitors let you define a new operation without changing the classes of the elements on which it operates". Visitors can certainly be used for testing objects on things other than type, and for carrying out operations on objects that don't involve testing.

"Visitor is overkill" is frequently stated, but it's usually said by people trying to use Visitor for things it wasn't intended for, and then finding that -surprise - it doesn't really work for it.

The poster is right in that the second piece of code they quote is a much easier way of implementing the functionality, but it misses the point in that Visitor is intended for when you don't want to modify the Fruit class.

·深蓝 2024-12-25 21:45:01

向每个子类添加特定于类的价格实现。

关键是,有时Visitor 是多余的,并且可以以不太抽象的方式添加功能。

现在,水果有一个价格是否有意义是一个不同的问题。让 Item 有一个价格,并且该 Item 有一个 FruitFruit 可能更有意义成为 Item 的子类,或者它们被组合,或者...

Add a class-specific price implementation to each sub-class.

The point is that sometimes a Visitor is overkill, and functionality can be added in a less-abstract fashion.

Now, whether or not it makes sense for a Fruit to have a Price is a different issue. It might make more sense for an Item to have a price, and that Item has a Fruit, or Fruit becomes a subclass of Item, or they're composited, or...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文