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

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

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

我认为它有2种选择:

创建一个类，该类具有Graphics2D的实例，并且具有与Graphics2D和setViewport相同的所有方法，并且仅在Graphics2D实例上调用相应的方法。

子类Graphics2D，仅添加setViewport方法，然后将其从Graphics2D强制转换为该新类

我尝试＃2是因为＃1似乎非常不切实际，但遇到了ClassCastException。我无法将Graphics或Graphics2D强制转换为这个新类。当我在强制转换之前打印图形对象(Graphics或Graphics2D)时，两者都以sun.java2d.SunGraphics2D的形式出现。

在尝试继承和转换时，我在做一些根本错误的事情吗？如果没有，我该如何解决此问题？

最佳答案

OO设计的一个原则是“偏向于继承而不是继承”，这是通过使用包装器类或装饰器设计模式来实现的(在我看来，这是类(class)幻灯片中包装器的含义)。因此，实际上由于多种原因，您所做的只是一种优雅的解决方案:

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

以这种方式继承违反了封装，从长远来看使软件易碎且容易出错。

使用组合可以保护您的类免于将来与您进行编写的类的更改，您的类会将所有方法调用转发到它的private Graphics2D实例，并分别处理变换坐标。

它还允许将来轻松扩展，使用继承将您与Graphics2D的当前实现联系在一起，这可能会限制类的性能。

Java API中存在一个这样的示例:Properties类扩展了HashTable，这说明了继承的不当使用，因为Properties不是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)的存在(例如上述Set的HashSet接口(interface))使编写此类变得更加容易，尽管我不知道Graphics2D是否存在这样的接口(interface)。

资料来源:有效的Java 2nd Edition-Joshua Bloch

关于java - 用于2D游戏引擎的Graphics2D包装器，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/39005336/