当我用opengl，direct3d，sdl或任何图形api（游戏，一般）编程任何类型的应用程序时，我习惯创建一个名为Graphics的类，它具有绘制，加载图像，初始化窗口所需的一切等等。在另一个类中有一个这个类的实例，它是程序或游戏的主要类，或任何将要使用它的类。
随着岁月的流逝，我尝试了很多不同的方法来使用它，我想知道你们是否认为其中一些是好的，或者如果一切都只是无用的废话，我应该采取另一种方式。
1 - 在程序类中有一个Graphics实例，并在程序类中有一个函数来迭代对象（例如游戏对象，比如播放器），并调用Graphics方法来相应地绘制所有内容。
2 - 将指向Graphics的指针传递给每个对象，这样每个对象都可以有一个Draw函数，并通过这个指针调用相应的Graphics函数。
3 - 让Graphics内部的所有内容都是静态的，无需创建图形实例。然后你可以从任何地方调用每个图形函数。（你只需要对每个对象都有一个Draw函数，就像主题2一样）
谢谢。
编辑：如果我创建类似于iostream与cout的相似之处，比如，只需使用'extern Graphics x;'创建一个标头，在cpp文件中声明x，然后，从这个x调用一切。这太糟糕了吗？如果是，为什么？
答案 0 :(得分：2)
我会选择第四个选项，将Graphics设为命名空间，而不是类。
听起来不像是图形是一种数据类型，只是一组函数。这正是命名空间的用途。
答案 1 :(得分：2)
我无法弄清楚“图形”对象是什么。软件中的对象类似于现实生活中的对象，那么Graphics对象代表什么呢？
我通常这样做的方式与标准UI应用程序没有什么不同：我有一个可以多次实例化的Window类和一个继承自Window并且只实例化一次的MainWindow类。在那个MainWindow类中，我拥有将在整个执行过程中使用的所有图形资源（例如Direct3D设备对象）。
答案 2 :(得分：1)
嗯，我认为“图形”类很可能有一个状态，例如，它正在绘制的画布。因此，使它成为一个阶级是好的;通过创建一个类，你可以使同一组函数适用于不同类型的“画布”（opengl，directx，sdl等）
在你的选项中，我认为选项1将是最好的，但选项2将是最简单的（选项3是可怕的，因为它使代码依赖于全局变量，消除了代码的可重用性 - 它是黑客方法：D）。
选项1非常棒，因为你可以编写一个图形引擎，用它绘制的东西做智能事物：假设你有两个共享相同纹理的对象，但使用不同的网格。如果编程适当，图形引擎可以使用相同的渲染设置调用两个对象的“绘制网格”功能，在这种情况下是相同的纹理，这加快了渲染速度。选项2通常将单个对象的绘制函数组合在一起，从而导致对渲染设置进行更多更改。
然而，选项2更容易实现。如果你不需要很多渲染速度，我会选择这个，因为它的工作要少得多，并且会导致更合理的程序结构。为了实现选项1，就像我解释的那样，对象需要具有“渲染属性”等，需要与渲染引擎匹配，并且不同的绘制例程用于不同的绘制设置......与对象相比非常复杂 - 绘制函数只使用一组中心绘图函数，如Graphics类。
因此，如果您选择“大型项目”，请选择选项1.要获得快速结果，并且如果您不需要绘制很多内容，则选项2可能更好。选项1和2的可用性类似。
PS：对于迟到的编辑感到抱歉，但我的语法在之前的版本中很糟糕