java - 用于 2d 游戏引擎的 Graphics2D 包装器

Question

我正在尝试编写一个 2d 游戏引擎，并且正在尝试实现一个视口(viewport)系统，这样当我在某个视口(viewport)中绘图时，游戏坐标将转换为屏幕坐标，而无需手动执行转变。

我想要做的是创建一个添加 setViewport 方法的 Graphics2D 包装器。

我认为有两种选择:

1. 创建一个类，该类具有 Graphics2D 的实例，并具有与 Graphics2D 相同的所有方法以及 setViewport 并且只需调用Graphics2D 实例上的相应方法。

2. 子类 Graphics2D 并添加一个 setViewport 方法，然后从 Graphics2D 转换到这个新类

我尝试了 #2，因为 #1 看起来很不切实际，但遇到了 ClassCastException。我无法将 Graphics 或 Graphics2D 转换为这个新类。当我在转换前打印图形对象(Graphics 或 Graphics2D)时，两者都显示为 sun.java2d.SunGraphics2D。

我在尝试子类化和强制转换时做错了什么吗？如果没有，我该如何解决这个问题？

Answer 1

一个 OO 设计原则是“优先组合而不是继承”，这是使用包装类 或装饰器 设计模式(这是在我看来，类(class)幻灯片中的 wrapper 是什么意思)。因此，出于多种原因，您所做的实际上是优雅的解决方案:

• 它可以防止 Graphics2D 中 future 的实现更改，如果您使用继承并且不幸地向 Graphics2D 添加了一个新方法，其签名与您的新方法相同方法和不同的返回类型，你的类将不再编译。如果您使用相同的签名和返回类型，您将覆盖 Graphics2D 中的新方法，这可能(并且已经)导致几天令人沮丧的调试。

• 这种方式的继承违反封装，从长远来看使软件脆弱且容易出错。

• 使用组合你可以保护你的类免受你组合的类 future 的变化，你的类将转发所有方法调用到它是私有(private)的 Graphics2D 实例并分别处理变换坐标。

• 它还允许将来轻松扩展，使用继承会将您绑定(bind)到 Graphics2D 的当前实现，可能会限制您的类的性能。

Java API 中存在这样的示例:Properties 类扩展了 HashTable，这说明了继承的不当使用，因为 Properties < em>不是 HashTable，它不应该以相同的方式使用。在这种情况下，调用 Properties p.getProperty(key) 可能会给出与 p.get(key) 不同的结果，因为后一种情况不考虑默认值.

装饰器设计模式:

public class Wrapper {
    private WrappedClass w;

    public Wrapper(WrappedClass w) {
       this.w = w;  
    }

    // Forward calls to WrappedClass methods to the private instance.
    public ReturnType example(Argument a) { return w.example(a); }

    // Add your methods here:
}

虽然这看起来是一种乏味的方法，但从长远来看，由于上述原因，它是值得的。此外，Java API 中接口(interface)的存在，例如上面 HashSet 的 Set 接口(interface)，使得编写此类类更容易，尽管我不知道这样的接口(interface)是否存在于 Graphics2D.

来源:Effective Java 第 2 版 - Joshua Bloch