编写 3D 图形软件时的类层次结构
这是一个方法论问题。
在编写使用面向对象的库来抽象 OpenGL 等的软件时，您是否应该（或愿意）选择扩展 OpenGL 辅助对象并向其添加您自己的业务逻辑，或者创建您的基本业务对象，然后拥有OpenGL 助手作为它们的属性。
例如，
假设我有一个 OpenGL 库，它提供了一个
OpenGLBillboard
类，它绘制一个面向相机的 2D 精灵
，如果我有某种要使用该类渲染的业务对象，那么简单地扩展 OpenGLBillboard 并构建是否明智？在它之上，或者我应该有一个 OpenGLBillboard 对象，它是我的软件中本质上的基类的属性？
在这种情况下，继承似乎是危险的，因为如果基类由于需求而必须更改，那么重构可能会很痛苦……而如果我只是走属性路线，我需要编写更多的前期样板文件。
你的想法？
谢谢
请原谅我说“业务对象”。我只是不想在有关 3D 的主题中大量使用“模型”，以免人们对我的含义感到困惑。
This is sort of a methodology question.
When writing software that makes use of object-oriented libraries to abstract OpenGL and the like, should you (or would you) choose to extend the OpenGL helper objects and add your own business logic onto them, or create your basic business objects and then have the OpenGL helpers as a property of them.
For example
Let's say I have an OpenGL library that provides a class
OpenGLBillboard
which draws a 2D sprite that faces the camera
if I have some sort of business object that is going to be rendered using that class, is it wise to simply extend OpenGLBillboard and build on top of it, or should I just have an OpenGLBillboard object that is a property on what is essentially a base class in my software?
It seems like inheritance in this case could be dangerous because if the base class ever has to change due to requirements, the refactoring could be painful ... whereas if I just go the property route, I have a little more upfront boilerplate to write.
Your thoughts?
Thanks
P.S. forgive me for saying "business object". I just didn't want to say "model" a whole lot in a topic about 3D and have people be confused as to my meaning.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
就我个人而言，我可能会让我的业务对象（私下）包含一个“Billboard”实例，并且根本不将其直接与 OpenGL 绑定。
只需要求业务对象进行渲染，并通过 Billboard 实例重定向其方法。这将允许您更换不同的实现（如果您决定使用 Billboard 以外的其他东西）或不同的后端（即：Direct3D 渲染管道），而无需更改业务对象。
Personally, I would probably have my business object contain (privately) a "Billboard" instance, and not tie it directly to OpenGL at all.
The business object would just be asked to render, and redirect it's methods through the Billboard instance. This would allow you to swap out a different implementation (if you decide to go with something other than a Billboard) or a different backend (ie: a Direct3D rendering pipeline) without changing the business object at all.