Как применить Data Oriented Design с объектно-ориентированным программированием? [закрыто]

Закрыто . Этот вопрос должен быть более сфокусированным . В настоящее время не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он был сосредоточен только на одной проблеме, отредактировав этот пост .

Закрыто 4 года назад .

Я прочитал много статей о Data Oriented Design (DOD), и я понимаю это, но я не могу разработать систему объектно-ориентированного программирования (OOP) с учетом DOD, я думаю, что мое OOP-образование блокирует меня. Как я должен думать, чтобы смешать два? Цель состоит в том, чтобы иметь хороший интерфейс ООП при использовании DOD за кулисами.

Я тоже это видел, но мало помогло: /programming/3872354/how-to-apply-dop-and-keep-a-nice-user-interface

c++ architecture

— Помбаль
источник

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

— DeadMG

Вы правы, но я не видел, чтобы это обсуждалось в других областях, кроме программирования игр.

— Помбал

@DeadMG: я никогда не видел термин, ориентированный на данные, который используется вне разработки игр, за исключением случаев, когда речь идет о методах, возникающих при разработке игр. Если вы думаете о дизайне, управляемом данными, это не одно и то же.

Я бы сказал, что блог Ноэля Ллописа, вероятно, лучшая инструкция для сочетания объектно-ориентированного программирования и ориентированного на данные дизайна. Он является одним из создателей термина DOD, является сильным программистом на C ++ и много писал о своем стиле и о том, как он использует возможности OO в C ++.

Я думаю, если бы я назвал ключевые элементы их объединения, согласно Ноэлю:

Используйте как можно больше функций POD и не-членов, не-друзей. Функции, не являющиеся членами, не являющиеся друзьями, улучшают инкапсуляцию и являются ключевой частью ориентации данных, поскольку они хранят данные, данные.
Избегайте хранения «временного» состояния на ваших объектах. Временное состояние забивает ваши данные. Если вам нужно что-то кэшировать (например, для производительности), то это относится к новому классу, причем функции, не являющиеся членами-не-друзьями, связывают два типа, а не отношения is-a или has-a.
Избегайте объектов, которые могут находиться в состоянии A или состоянии B. Предпочитайте переключение между двумя объектами, один из которых - A, а другой - B.
Избегайте полиморфизм, остерегайтесь виртуальные функции, шаблоны , остерегайтесь, избегать всего , что делает ваши данные имеют синтаксический внешний вид однообразия , а не фактическая тождественности.

Другое известное имя в пропаганде DOD сейчас - Майк Актон из Insomniac, но, читая то, что он написал, я бы сказал, что он на самом деле не сторонник ОО (или анти-ОО, если он все еще ориентирован на данные).

Спасибо за ответ, но вы должны сказать, что я должен сделать, чтобы использовать DOD, а не то, как я мог бы использовать OO с ним. Я читал блог Ноэля, скандалы Майка Актона (: D), публикации DICE и другие, и я понимаю, как использовать DOD, но только не с ОО.

— Pombal

Как вы думаете, что ОО? Например, я бы назвал большую часть кода Noel OO - все еще есть классы и экземпляры, все еще есть диспетчеризация на основе типов, все еще может быть наследование (определение POD в C ++ 0x было изменено, чтобы разрешить это). Можно по-прежнему моделировать проблемы, начиная с данных, а не с операций.

Например, полиморфизм является важной частью ООП, как состояния объекта. Проект, ориентированный на данные, должен обеспечивать такие свойства игровой сущности, как одушевленность, взаимодействие, перемещение, ... наследование. Все зависит от умного менеджера данных, который предоставляет только необходимые объекты для каждого компонента, например, для физики или анимации.

— Данияр

@Sharethis: Если я понимаю ваше возражение, это то, что полиморфизм подтипов является ключевой особенностью ОО. Я согласен, что язык, претендующий на то, чтобы быть ОО без поддержки, был бы странным, но это не значит, что он является средством первой инстанции для тех проблем, с которыми сталкиваются программирующие игры, даже если игра программируется в ОО-стиле . Я также утверждаю, что DOD действительно избегает определенных видов полиморфизма (номинального подтипа), но поощряет других (в C ++, специальный полиморфизм с ADL или структурный полиморфизм через гарантии представления значений).