运行时动态选择方法；访客模式或反射的替代方案

我正在开发一个小型游戏模板，其世界由如下节点组成：

World
|--Zone
|----Cell
|------Actor
|------Actor
|--------Item

Where a World可以包含多个Zone物体，一个Zone可以包含多个Cell对象等。

其中每一个都实现了Node接口，其中有一些方法，例如getParent, getChildren, update, reset等等。

我希望能够执行给定的Task在单个节点上或从节点递归地沿着树向下（由Task).

为了解决这个问题，我希望这是一个“可插入”系统，这意味着我希望玩家/开发人员能够动态向树中添加新类型。我还考虑过从基本类型进行转换：

public void doTask(Actor node)
{
    if(!(node instanceof Goblin)) { return; }
    Goblin goblin = (Goblin) node;
}

最初我被吸引使用访客模式 https://en.wikipedia.org/wiki/Visitor_pattern利用双重调度，允许每个例程（访问者）根据访问者的类型进行操作Node被访问。然而，这导致了一些并发症，特别是当我想添加一个新的Node键入树。

作为替代方案，我写了一个实用类 https://github.com/floralvikings/jenjin/blob/node-overhaul/jenjin-world-core/src/main/java/com/jenjinstudios/world/reflection/DynamicMethodSelector.java它使用反射来查找适用于的最具体的方法Node.

我现在关心的是性能 https://stackoverflow.com/questions/435553/java-reflection-performance;由于将会有相当大量的反射查找和调用，我担心我的游戏的性能（每秒可能有数百或数千个此类调用）会受到影响。

这似乎解决了两种模式的问题，但使每个新的代码Task uglier.

在我看来，我有三个选项来允许这种动态调度（除非我错过了一些明显/模糊的东西，这就是我在这里的原因）：

1. Visitor Pattern
   • Pros
     • 双重派遣
     • 表现
     • 任务中的整洁代码
   • Cons
     • 很难添加新的Node类型（不修改原始代码是不可能的）
     • 任务调用期间的丑陋代码
2. Dynamic Invocation using Reflection
   • Pros
     • 可以添加新的Node放弃类型
     • 非常可定制的任务
     • 任务中的整洁代码
   • Cons
     • 表现不佳
     • 任务调用期间的丑陋代码
3. Casting
   • Pros
     • 比反射性能更高
     • 可能比访客更有活力
     • 任务调用期间干净的代码
   • Cons
     • 代码气味
     • 性能低于 Visitor（没有双重调度，每次调用都进行强制转换）
     • 任务中的丑陋代码

我在这里错过了一些明显的事情吗？我熟悉“四人帮”的许多模式，以及《四人帮》中的模式。游戏编程模式 http://gameprogrammingpatterns.com/。任何帮助将不胜感激。

需要明确的是，我并不是在问其中哪一个是“最好的”。我正在寻找这些方法的替代方案。

因此，在对 Java 8 Lambda 以及如何反射式构建它们进行一些研究之后，我提出了创建一个BiConsumer来自Method我通过反射获得的对象，第一个参数是应调用该方法的实例，第二个参数是该方法的实际参数：

private static <T, U> BiConsumer<T, U> createConsumer(Method method) throws Throwable {
    BiConsumer<T, U> consumer = null;
    final MethodHandles.Lookup caller = MethodHandles.lookup();
    final MethodType biConsumerType = MethodType.methodType(BiConsumer.class);
    final MethodHandle handle = caller.unreflect(method);
    final MethodType type = handle.type();

    CallSite callSite = LambdaMetafactory.metafactory(
          caller,
          "accept",
          biConsumerType,
          type.changeParameterType(0, Object.class).changeParameterType(1, Object.class),
          handle,
          type
    );
    MethodHandle factory = callSite.getTarget();
    try {
        //noinspection unchecked // This is manually checked with exception handling.
        consumer = (BiConsumer<T,U>) factory.invoke();
    }catch (ClassCastException e) {
        LOGGER.log(Level.WARNING, "Unable to cast to BiConsumer<T,U>", e);
    }
    return consumer;
}

一旦这个BiConsumer已创建，它被缓存在HashMap使用参数类型和方法名称作为键。然后可以像这样调用它：

consumer.accept(nodeTask, node);

这种调用方法几乎完全消除了反射引起的调用开销，但它确实有一些问题/限制：

• Because of the use of BiConsumer, only one parameter may be passed into the method (the first argument to the accept method must be the instance that should have the method invoked on it).
  • 这对于我的目的来说很好，无论如何我只想传递一个参数。
• There is a non-trivial performance overhead when invoking a method with parameter types that haven't been seen before, as it must first be searched for reflectively.
  • 再说一遍，就我的目的而言，这是可以的；可接受的节点类型的数量不会很大，并且会在看到它们时快速缓存。在第一次“发现”参数类型组合的适当方法之后，开销非常小（我相信是恒定的，因为它是一个简单的HashMap抬头）。
• 需要 Java 8（反正我已经在使用了）

我可以通过使用自定义功能接口（类似于Invoker类而不是Java的BiConsumer）但截至目前，它完全符合我想要的性能。