1

我目前正在构建一个游戏引擎（这与 2d 渲染器更相关），我想知道是否有一个不好的做法，例如，有一个对象 Image 只保留图像的 url、宽度和高度。然后，当您渲染此图像时，渲染器将请求加载图像，并且渲染器也知道如何渲染图像。

为什么我选择了这样的方法？

  • 目前我使用画布，但有时我想用标签渲染图像，而不是绘制到画布上。当然，我希望最终用户（使用 Image 类的人）完全抽象它。如果图像是在画布上绘制的，或者在标签中，ti 应该取决于渲染器，它认为什么具有更高的性能......

矩形也将具有 ax、y、宽度和高度，但它不知道如何绘制自己，渲染器绘制矩形。

这种方法可能有什么不好的地方？

4

1 回答 1

1

显然，这取决于。

你问的是一个比“我的节点应该自己渲染”更难的问题。

如果您想要更一般的问题“我应该如何设计我的对象/类？”的真正 OOP 答案，请查看Bob 叔叔的 SOLID 设计原则。或者只是搜索“SOLID Design”。

在这种特定情况下，我会说拥有仅代表该数据的对象和能够绘制这些对象的其他对象是一个完全有效的想法。通过这种方式，您可以将相同的“数据对象”用于该数据的多种不同类型的视图，例如您当前正在解释的。

您的想法是边界线 MVC 或 MVVM（原则上），因此并非没有优点。

我想知道是否是一种不好的做法，例如让一个对象 Image 只保留图像的 url、宽度和高度。

简单地说，没有。这本身并不是坏习惯。它被称为“图像”的事实很糟糕，因为这是用于创建<img>标签的现有“类”。最好为此选择一个不同的名称。

然后，当您渲染此图像时，渲染器将请求加载图像，并且渲染器也知道如何渲染图像。

这闻起来很复杂。该对象将需要处理加载图像时的回调，或者找到某种同步加载图像的方法（如果可能的话，这很糟糕）。它还需要知道当图像无法加载时该怎么做。我可能会考虑在前面提到的“数据对象”上使用承诺来帮助解决部分复杂性，因为任何使用数据对象的类很可能需要加载图像。

另一个观察：你使用术语“渲染器”就像它是一个包罗万象的东西，可以渲染任何东西，因为它的唯一责任就是能够做这件事。如果这就是你的想法，那么从长远来看，这不会有那么好的结果。需要有特定的对象知道如何以某种方式呈现其他纯数据对象。那些“视图”对象将知道如何使用某种“渲染”api 来绘制那些仅数据对象，但绘图 api 应该被认为是一种实用程序，或者是隐藏绘制原始对象复杂性的东西。不要将其视为您知道如何“绘制任何东西/一切”的“找人”。

矩形也将具有 ax、y、宽度和高度，但它不知道如何绘制自己，渲染器绘制矩形。

听起来不错。通过这样做，您允许以您需要的任何方式绘制矩形。例如，红色、蓝色、径向渐变、根据某个矩阵进行变换等。

这种方法可能有什么不好的地方？

任何东西......一切......什么都没有......但很可能是不必要的复杂性。假设复杂性实际上是不需要的。

有时我们只需要编写一些代码来找出答案。

只是不要浪费时间去思考“我将来需要使用哪些方法”或“我如何使它成为可能的最通用的解决方案”，因为你最终会花费大量时间无所作为。

于 2013-04-01T22:47:27.597 回答