Какова цель создания класса, который создает экземпляры всех других классов и подсистем

Question

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

Многие из них имеют один определенный класс (вероятно, это одиночный пакет), который загружает ресурсы, создает экземпляры всех других классов, подсистем, связывает их друг с другом и подготавливает структуру объектов, которая используется во время выполнения. Почему бы не сделать это в main()?

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

Answer 1

Есть несколько причин иметь класс менеджера:

• Это делает вещи немного более последовательными. Если остальная часть вашего проекта написана в коде в стиле ООП, то иметь основной класс таким же образом - это немного лучше.
• Во многих случаях это облегчает тестирование. main нельзя назвать в C ++; если все в конструкторе класса, ваши тесты могут вызывать это довольно свободно.
• Это позволяет вам иметь несколько «глобальных» систем одновременно. Очевидно, что полезность этого зависит от проекта, но, как правило, удаленно необоснованно, например, запускать две системы параллельно для обеспечения согласованности.
• Он может представить более простой API для взаимодействия с библиотекой, так что функции, которые влияют на несколько подсистем, могут быть методом класса менеджера вместо свободной функции, принимающей параметр для каждой подсистемы. Это особенно ценно в чем-то вроде библиотеки графического интерфейса или игрового движка, где для правильной работы может потребоваться регистрация простого действия (скажем, добавление кнопки) в нескольких подсистемах (рендеринг, обработка ввода мышью, обработка ввода с клавиатуры).
• Это может облегчить замену подсистем на другие серверные части. Например, если у вас есть один сервер, который выполняет рендеринг с OpenGL, а другой - с DirectX, вы можете просто заставить их реализовать один и тот же интерфейс «подсистемы рендеринга» и изменить всю систему один раз, во время компиляции, на уровне всей системы. программа, без необходимости менять каждое упоминание или использовать typedef s и рассчитывать на людей, включая правильные заголовки.

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

Answer 2

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

Эта часть анализа иногда упоминается как вариант использования (функция), называемый «Запуск». Книга Крейга Лармана о OOAD называет это исходным доменным объектом идиома (не совсем шаблон):

Как запускаются приложения?

Сценарий startUp или инициализации системной операции Start * абстрактно представляет фазу инициализации выполнения при запуске приложения. Чтобы понять, как разработать диаграмму взаимодействия для этой операции, вы должны сначала понять контексты, в которых может происходить инициализация. Способ запуска и инициализации приложения зависит от языка программирования и операционной системы.

Во всех случаях общая конструкция заключается в создании исходного объекта домена или набора равноправных начальных объектов домена, которые являются первыми созданными программными объектами «домена». Это создание может происходить явно в начальном методе main или в объекте Factory , вызываемом из метода main .

Часто первоначальный объект домена (в единственном случае) после его создания отвечает за создание своих прямых дочерних объектов домена. Например, Store , выбранный в качестве исходного объекта домена, может отвечать за создание объекта Register .

Например, в приложении Java метод main может создать начальный объект домена или делегировать работу объекту Factory , который его создает.

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

Выберите в качестве исходного объекта домена класс в или около корня иерархии включения или объединения объектов домена. Это может быть контроллер фасада, например Register, или другой объект, который, как считается, содержит все или большинство других объектов, например Store.

Последнее относится к доменной модели для приложения Point of Sale, где Store и Register являются классами.

Answer 3

Этот класс называется «Корнем компоновки» и используется с программными модулями, которые поддерживают внедрение зависимостей.

Он позволяет деталям быть независимыми друг от друга, объединяя зависимости между ними в один,отдельный модуль, определяющий приложение в целом.

Возможно, начните здесь: Что такое корень композиции в контексте внедрения зависимостей

Answer 4

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

Factory Pattern, регистрирует объекты во время инициализации, которая, в свою очередь, порождает объекты позже в программе. Этот шаблон также подходит, если новые объекты должны быть интегрированы в вашу систему, скажем, новый плагин