我正在尝试编写一个 2d 游戏引擎,并且正在尝试实现一个视口(viewport)系统,这样当我在某个视口(viewport)中绘图时,游戏坐标将转换为屏幕坐标,而无需手动执行转变。
我想要做的是创建一个添加 setViewport
方法的 Graphics2D
包装器。
我认为有两种选择:
创建一个类,该类具有
Graphics2D
的实例,并具有与Graphics2D
相同的所有方法以及setViewport
并且只需调用Graphics2D
实例上的相应方法。子类
Graphics2D
并添加一个setViewport
方法,然后从Graphics2D
转换到这个新类
我尝试了 #2,因为 #1 看起来很不切实际,但遇到了 ClassCastException
。我无法将 Graphics
或 Graphics2D
转换为这个新类。当我在转换前打印图形对象(Graphics
或 Graphics2D
)时,两者都显示为 sun.java2d.SunGraphics2D
。
我在尝试子类化和强制转换时做错了什么吗?如果没有,我该如何解决这个问题?
最佳答案
一个 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
关于java - 用于 2d 游戏引擎的 Graphics2D 包装器,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39005336/