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

Question

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

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

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

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

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

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

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

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

Мои вопросы:

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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