我目前正在构建一个游戏引擎(这是更相关的2d渲染器)，我想知道如果这是不好的做法，例如，有一个对象图像，只保持url，宽度和高度的图像。然后当你渲染这张图片时，渲染器会请求加载图片，并且渲染器也知道如何渲染图片。
为什么我选择了这样的方法?
- 目前我使用画布，但有时我想用标签渲染图像，而不是绘制到画布上。当然，我希望它完全被最终用户(使用Image类的人)抽象。如果图像是在画布上绘制的，或者在一个标签中，它应该由渲染器和它认为有更多的性能…
一个矩形也有x, y，宽度和高度但是它不知道如何绘制自己，渲染器绘制矩形。
这种方法有什么不好的地方?
显然，这要看情况。
你在问一个比"我的节点应该呈现自己"更难的问题。
如果你想要真正的OOP答案来回答"我应该如何设计我的对象/类?"这个更普遍的问题，请查看Bob大叔的SOLID设计原则。或者直接搜索"SOLID Design"。
在这个特定的场景中，我认为让对象只表示数据和其他能够绘制这些对象的对象是一个完全有效的想法。通过这种方式，您可以对该数据的多个不同类型的视图使用相同的"数据对象"，例如您当前正在解释的视图。你的想法是边界MVC或MVVM(原则上)，所以它不是没有优点。
我想知道如果是一个坏的做法，例如有一个对象图像，只保持url，宽度和图像的高度。
简单地说，没有。这本身并不是一个坏习惯。它被称为"Image"的事实是不好的，因为这是一个用于创建<img>标记的现有"类"。最好为它取一个不同的名字。
当你渲染这个图像时，渲染器会请求加载图像，并且渲染器也知道如何渲染图像。
这闻起来很复杂。这个对象需要处理图像加载时的回调，或者找到一些同步加载图像的方法(这是不好的，如果可能的话)。它还需要知道当图像加载失败时该怎么做。我可以考虑在前面提到的"数据对象"上使用承诺来帮助解决部分复杂性，因为任何使用数据对象的类都很可能需要加载图像。
另一个观察:你使用术语"渲染器"就像它是一个包揽一切的东西，可以渲染任何东西，因为它的唯一责任是能够做那一件事。如果你是这么想的，那么从长远来看，这不会有什么好结果。需要有特定的对象知道如何以某种方式呈现其他仅数据对象。那些"视图"对象将知道如何使用某种"渲染"api来绘制那些数据对象，但是绘图api应该被认为是一个实用程序，或者是隐藏绘制原始对象复杂性的东西。不要认为它是你的"去的家伙"，知道如何"画任何东西/一切"。
矩形也有x, y，宽度和高度但是它不知道如何绘制自己，渲染器绘制矩形。
听起来不错。通过这样做，您允许以您需要的任何方式绘制矩形。例如，红色，蓝色，径向梯度，根据某些矩阵变换等
这种方法有什么不好的地方?
什么……一切……没有什么……但最有可能的是，不必要的复杂性。假设复杂性实际上是不需要的。
有时我们只需要编写一些代码来找出答案。
只是不要浪费时间去想"我将来需要使用它的所有方法"或"我如何使它成为最通用的解决方案"，因为你最终会花很多时间一无所获。