Государство с пространствами имен и местными жителями - или классы? - PullRequest
Новая
       10

Государство с пространствами имен и местными жителями - или классы?

3 голосов
/ 26 февраля 2011

Прямо сейчас модули в моем игровом движке организованы как пространства имен. У них есть функции Open () и Close (), которые действуют аналогично конструкторам и деструкторам классов и вызываются при входе в игру слева.

Примеры для этих модулей: Менеджер физики, Менеджер сущностей, Обработчик ввода / вывода, Менеджер рендеринга.

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

Преобразование модулей из пространств имен в классы приведет к следующим издержкам:

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

  • Взаимодействие между модулями может привести к дополнительным издержкам при вызове функции и 1-2 разыменования указателя

И следующие преимущества:

  • RAII соответствует
  • Все состояния могут быть упакованы в один класс CState, который содержит экземпляры модулей
  • Хорошо для того, чтобы убедиться, что ресурсы удалены и правильно распределены

Мои вопросы:

  • Должен ли я рассмотреть вопрос о реорганизации моих модулей двигателя из пространств имен в управляемые классы? Почему (нет)?

Ответы [ 2 ]

4 голосов
/ 26 февраля 2011

Если у вас есть набор функций (методов), которые работают с набором объектов, которые не должны быть видны другим функциям за пределами этого набора, то было бы естественным поместить этот набор функций и объектов в класс.

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

Должен ли быть глобальный контроллер? Это звучит очень похоже на анти-паттерн "Объект Бога". Даже если у вас обычно есть только один экземпляр каждого из ваших классов, они не обязательно должны быть членами общего класса контроллера, если функции различных классов, которым требуется доступ к другим классам, могут получить этот доступ.

Взаимодействие между модулями может привести к дополнительным накладным расходам на вызов функции и 1-2 разыменования указателя

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

0 голосов
/ 11 января 2013

Если задействовано состояние, то создание класса, чтобы вы могли иметь несколько экземпляров состояния, хорошо.

Однако есть и другие плюсы и минусы:

  • пространства имен открыты, классы закрыты.Вы можете добавлять вещи в пространство имен более просто.

  • Вы можете более легко создавать объявления вещей в пространствах имен.Вы не можете делать предварительные объявления вещи в классе - все объявление класса должно быть видимым.

  • это означает, что пространства имен немного легче сделать моральным эквивалентом PIMPL.Вы можете просто объявить нужные вам функции.С классом вам нужно создать PIMPL - это утомительно.

Я хотел бы думать, что пространство имен - это просто класс, в котором нет данных, или класс, который толькосодержит статические данные класса.Т.е. пространство имен - это что-то вроде класса, в котором вы не можете иметь объекты.Но, к сожалению, многие ограничения C ++ не позволяют этому быть буквально истинным.

  • Иногда я получаю и пространство имен, и класс.
...