使用复合类：客户端如何确定它是否是复合类

Question

我知道这个here 有一个类似的问题。它考虑了一个比我这里的问题更通用的类特定行为问题。

考虑以下复合模式的简单实现：

interface Item {
    int getWeight();
}

class SimpleItem implements Item {
    private int weight;
    public int getWeight() {
        return weight;
    }
}

class Container implements Item {
    private List<Item> items;
    private int weight;
    public void add(Item item) {
        items.add(item);
    }
    public int getWeight() {
        return weight + items.stream().mapToInt(Item::getWeight).sum();
    }
}

现在考虑 Item 的用户如何确定它是否是一个容器。例如，Container pushAdd 中需要一个方法，该方法将项目向下推送到其中没有容器的容器。容器只知道 Items，它不知道这些项目是 Containers 还是 SimpleItems 或其他实现 Item 的类。

有三种可能的解决方案：

1。 使用实例和强制转换

public void pushAdd(Item item) {
    Optional<Container> childContainer = items.stream()
        .filter(item instanceof Container)
        .map(item -> (Container)item)
        .findAny();
    if (childContainer.isPresent()) {
        childContainer.get().pushAdd(item);
    } else {
        add(item);
    }
}

2。 实现 is/as 方法

public pushAdd(Item item) {
    Optional<Container> childContainer = items.stream()
        .filter(Item::isContainer)
        .map(Item::asContainer);
    ....
}

3。 访问者模式（我省略了简单的 accept 实现）。

interface ItemVisitor {
    default void visit(SimpleItem simpleItem) { throw ...}
    default void visit(Container container) { throw ... };
}

public pushAdd(Item item) {
    Optional<Container> childContainer = ... (using instanceOf);
    if (childContainer.isPresent()) {
        childContainer.get().accept(new ItemVisitor(item) {
            void visit(Container container) {
                container.pushAdd(item);
            }
        };
    } else {
        add(item);
    }
}

第一个是邪恶的，因为它使用 instanceof 和强制转换。第二个是邪恶的，因为它将 Container 的知识强加到 Item 中 - 当创建 item 的其他子类时，情况会变得更糟。第三个不能帮助您在调用访问者之前知道您是否可以添加到 Item 中。您可以捕获异常，但这对我来说似乎是对异常的滥用：最好在访问之前有办法检查。

所以我的问题是：是否可以使用另一种模式来避免强制转换和 instanceof，而不必将子类的知识推到层次结构上？

Answer 1

当我说访问者模式在 Java 中并不完全流行时，我想我代表任何一个 Java 人。所以上面可以这样实现（我将在这里使用接口，因为根据我的经验它们更灵活）：

interface Item { /* methods omitted */ }

interface SimpleItem extends Item { /* methods omitted */ }

interface ContainerItem extends Item { /* methods omitted */ }

// telling clients that this can throw an exception or not
// here is a whole different design question :)
interface ItemVisitor { void visit(Item i) /* throws Exception */; }

class MyVisitor implements ItemVisitor {
  void visit(Item i) {
    if (i instanceof SimpleItem) {
      // handle simple items
    } else if (i instanceof ContainerItem) {
      // handle containers using container specific methods
    } else {
      // either throw or ignore, depending on the specifications
    }
  }
}

instanceof 的成本在最新的 JVM 上相当低，所以我不会太担心，除非你能证明传统的访问者要快得多。

代码的可读性和可维护性可以说是相同的，但有一些差异。首先，如果将新界面添加到不修改现有访问者的层次结构中，则不需要更改这些访问者。另一方面，更容易忽略确实需要更改的访问者（尤其是在您无法控制的客户端代码中），因为访问者没有明确要求客户端这样做，但是，嘿，这就是维护代码的本质以及需要访问的设计的一般缺点。

此模式的另一个优点是不需要访问的客户无需担心（没有accept 方法），即学习曲线更短。

最后，我认为这种模式更接近于“纯粹的”OOD，因为接口层次结构不包含虚假方法（visit、canAddItems 等），即有no "tags" 的排序。

Answer 2

好吧，从没有人发布答案这一事实看来，没有比我提出的 3 个更好的选择了。

所以我会发布我的首选解决方案，看看是否有人可以改进它。在我看来，最好的选择是选项 2 和 3 的组合。我认为拥有 canAddItems 成员 Item 并不太邪恶 - 可以说，Item 的实现者告诉你是否可以添加是合理的给他们的物品。但访问者似乎是隐藏如何添加项目的详细信息的好方法。

所以，fwiw 这是我对我提出的问题的最佳妥协。我仍然不是 100% 满意。特别是，如果实现了另一个可以添加项目的类，则添加项目的访问者将中断。但这可能就是你想要的，因为它改变了 pushAdd 的语义。

interface Item {

    int getWeight();

    void accept(ItemVisitor visitor);

    default boolean canAddItems() {
        return false;
    }

}

interface ItemVisitor {

    default void visit(SimpleItem simpleItem) {
        throw new IllegalArgumentException("ItemVisitor does not accept SimpleItem");
    }

    default void visit(Container container) {
        throw new IllegalArgumentException("ItemVisitor does not accept Container");
    }
}

class SimpleItem implements Item {

    private int weight;

    public int getWeight() {
        return weight;
    }

    public void accept(ItemVisitor visitor) {
        visitor.visit(this);
    }
}

class Container implements Item {

    private List<Item> items;
    private int weight;

    public void add(Item item) {
        items.add(item);
    }

    public int getWeight() {
        return weight + items.stream().mapToInt(Item::getWeight).sum();
    }

    public void accept(ItemVisitor visitor) {
        visitor.visit(this);
    }

    public void pushAdd(Item item) {
        Optional<Item> child = items.stream().filter(Item::canAddItems).findAny();
        if (child.isPresent()) {
            child.get().accept(new ItemVisitor() {
                public void visit(Container container) {
                    container.add(item);
                }
            });
        } else {
            add(item);
        }
    }

}