您似乎正在寻找的是Abstract Factory模式。有几种方法可以实现它；这可能是您所需的最佳搭配：

interface ViewFactory<V extends View> {
    boolean canHandlePowerUp(PowerUp target);
    V createView(PowerUp target);
}

class FreezeViewFactory extends ViewFactory<FreezeView> { ... }

...

List<ViewFactory<? extends V>> factories;

View v = factories.stream()
    .filter(f -> f.canHandlePowerUp(p))
    .findFirst()
    .map(f -> createView(p))
    .orElseThrow(() -> new IllegalStateException("no ViewFactory found for " + p);

当您打算分离关注点时，这实际上是一个非常普遍的问题。例如，如果未将渲染与模型隔离开，那么您将有一个PowerUp.render()方法，以便他们可以自己渲染并每天调用它。

但是，您会遇到另一个问题，所有问题都将归结为一个类。这是一个折衷，您可以直接在对象上实现操作，也可以提取这些行为，然后必须以某种方式执行类型匹配。

这里的抽象工厂很有趣，因为它减少了您必须做出的基于类型的决策的数量，但是如果您需要做出其他基于类型的决策（例如，不同的上电声音），则必须再次进行类型匹配，没有办法了。

话虽如此，您可以使用Visitor Pattern实现可重用的类型安全机制来进行类型匹配。

例如（为简洁起见，省略了访问修饰符）

interface PowerUpVisitor {
    visit(Invincibility powerUp);
    visit(Freeze powerUp);
    visit(Fright powerUp);
}

interface PowerUp {
    accept(PowerUpVisitor visitor);
    ...
}

class Freeze implements PowerUp {
    accept(PowerUpVisitor visitor) { visitor.visit(this); }
}

class PlayPowerUpSound implements PowerUpVisitor {
    visit(Invincibility powerUp) { playInvicibilitySound(); }
    ...
}

class RenderPowerUp implements PowerUpVisitor {
    visit(Invincibility powerUp) { renderInvisibility(); }
    ...
}

//In practice you would most likely reuse the same visitor instances
somePowerUp.accept(new PlayPowerUpSound()); //to play sound
somePowerUp.accept(new RenderPowerUp()); //to render

此模式的主要优点是，与instanceof检查不同，现在编译器会告诉您是否忘记处理特定类型的上电。

与其他提议的抽象工厂解决方案一样，使用基于动态类型的解析，您必须使用反射来实现基于运行时的验证，以确保所有类型的工厂都存在。

对于抽象语法树之类的层次结构，访问者模式通常很自然地想到，但是在这里它同样有用。

如果您同意降低隔离度，也可以采用其他方法。例如，您可以针对PowerUp可能具有的各种行为（例如IPlaySound，IHaveAView等）引入专门的接口，并直接在开机时实施这些操作。边界现在仅由接口绘制，但它们仍然存在。

最后，您也可以要求其各自的渲染器或声音播放器通电，而不是直接由对象执行操作。我想我在这里比较喜欢访客，但是根据您所期望的复杂程度，有很多方法可以给猫咪剥皮。这都是权衡取舍的方法！