Я пытаюсь преобразовать старый код C ++ в более тестируемую форму. Чтобы соответствовать принципу обращения зависимостей (DIP), я буду использовать внедрение зависимостей во многих случаях.
Мой вопрос заключается в том, как лучше всего создавать конкретные классы. В этом коде есть что-то вроде 100 моих собственных классов. В своей книге «Чистая архитектура» Роберт Мартин утверждает, что эти классы нестабильны и должны быть созданы на фабриках. Однако (см. Стр. 90 книги) для этого потребуется 4 класса на класс, который я хочу создать. Это будет означать 400 классов.
Скажем для иллюстрации, что в старом коде есть класс A (который создает и использует классы от A1 до A5), B (от B1 до B10) и C (классы от C1 до C3).
В новом коде, как и где бы вы предложили создать экземпляр всех конкретных классов? Мне особенно было бы интересно услышать от любого, кто имел дело с этим типом проблемы в больших программах на C ++. Благодарю.
Брюс
Применяя принцип обращения зависимостей, мы откладываем построение графиков взаимодействующих компонентов (a.k.a. графов объектов) до последнего ответственного момента. Поскольку мы хотим свести к минимуму связь между компонентами и даже отдельными библиотеками, мы переместим построение этих графов объектов в наиболее изменчивую часть системы. Это начальная сборка. Часть в стартовой сборке, которая отвечает за составление и построение этих графов объектов, обычно называется Корень композиции.
В новом коде, как и где бы вы предложили создать экземпляр всех конкретных классов?
Вы должны построить все ваши конкретные компоненты (классы, которые содержат интересное поведение приложения) внутри Корень композиции.
В некоторых управляемых средах, таких как Java и .NET, наличие API, которые позволяют нам запрашивать метаданные приложения во время выполнения (или Reflection), позволяет объявлять отношения между абстракциями и реализациями во время компиляции и создавать компоненты. динамически во время выполнения с использованием повторно используемых библиотек, обычно называемых DI Контейнеры.
C ++ может не иметь возможности запрашивать метаданные во время выполнения. В такой среде вы используете Чистый DI, что просто означает: вы new
ваши уроки вручную внутри вашего Корень композиции.
Обратите внимание, что нигде в моем описании я не использовал слово «фабрика». Необходимость указывать фабричные абстракции, которые возвращают другие абстракции приложения, не должна быть нормой, но исключение. Вы можете видеть свой корень композиции как одну большую фабрику, но ничто в приложении не зависит от корня композиции. Корень композиции, с другой стороны, зависит от всего.
Таким образом, классы вашего приложения вряд ли должны зависеть от фабричных абстракций. Если класс требует другой службы, он должен просто вставить это в свой конструктор напрямую, а не внедрять фабрику, которая может разрешить эту службу.
Других решений пока нет …