Иерархия классов при написании программного обеспечения для 3D-графики - PullRequest
0 голосов
/ 14 декабря 2011

Это своего рода методологический вопрос.

При написании программного обеспечения, использующего объектно-ориентированные библиотеки для абстрагирования OpenGL и т. П., Если вы (или вы бы) решили расширить вспомогательные объекты OpenGL идобавьте к ним свою собственную бизнес-логику или создайте свои основные бизнес-объекты, а затем присвойте их помощникам OpenGL.

Например,

Допустим, у меня есть библиотека OpenGL, которая предоставляеткласс

OpenGLBillboard

, который рисует 2D-спрайт, обращенный к камере

, если у меня есть какой-то бизнес-объект, который будет отображаться с использованием этого класса, разумно ли этопросто расширить OpenGLBillboard и построить поверх него, или мне просто нужно иметь объект OpenGLBillboard, который является свойством того, что по сути является базовым классом в моем программном обеспечении?

Кажется, что наследование в этом случае может быть опаснымпотому что если базовый класс когда-либо должен измениться из-за требований, рефакторинг может быть болезненным ...тогда как, если я просто пройду по маршруту собственности, у меня будет еще несколько предварительных шаблонов для письма.

Ваши мысли?

Спасибо

PS простите меня за высказывание "бизнес-объект",Я просто не хотел много говорить «модель» в теме о 3D, и люди не могли понять, что я имею в виду.

1 Ответ

0 голосов
/ 14 декабря 2011

Лично я, вероятно, хотел бы, чтобы мой бизнес-объект содержал (в частном порядке) экземпляр "Billboard", а не связывал бы его напрямую с OpenGL вообще.

Бизнес-объект просто попросят отрендерить и перенаправить его методы через экземпляр Billboard. Это позволит вам заменить другую реализацию (если вы решите использовать что-то отличное от Billboard) или другой бэкэнд (например, конвейер рендеринга Direct3D) без изменения бизнес-объекта вообще.

...