Это будет зависеть от целого ряда факторов, в том числе:
- Вид взаимозависимостей между A, B и C (например, зависит от функциональности/метода, зависимости от данных или смеси?)
- Жизненный цикл каждого из A, B и C - синглетонов для каждого запроса (если это в контексте чего-то вроде веб-API), за разрешение или что-то еще
- Можно ли разрешить граф зависимостей при запуске приложения (например, полностью статически или на основе конфигурации запуска) или зависит от разрешения в зависимости от входов данных, которые доступны только во время выполнения (например, данные запроса для веб-API)
Как правило, для зависимостей, которые могут быть разрешены при запуске приложения, инъекция зависимостей через контейнер IoC - это путь.
Если вам нужны входы данных во время выполнения, то, как правило, фабрики являются правильным подходом, где вы можете предоставить входные данные данных в параметрах фабричным методам, а фабрика может возвращать правильно разрешенный экземпляр для этого набора входов. Обратите внимание, что сами фабрики по-прежнему должны быть полностью подключены к контейнеру IoC.
В первую очередь, для зависимостей данных, вы можете рассмотреть возможность создания сборщиков.
Для других сценариев, таких как пользовательский жизненный цикл, смешанные функциональные + зависимости от данных и т. Д., Возможно, вам придется использовать более индивидуальные подходы. Хотя, если что-либо, настройки, вероятно, будут иметь тенденцию больше к фабрикам или строителям, но, возможно, сами фабрики/строители все еще используют инъекцию и разрешение зависимостей через контейнер IoC.
Посмотрите, может ли наследование применяться, если не требуется инъекция зависимостей. – 11thdimension
Вы не выбрали языковой тег. Это намеренно? Или вы имели в виду один (моя догадка была бы Java)? Каким бы ни был ответ, не могли бы вы изменить свой вопрос, добавив либо тег «language-agnostic», либо соответствующий? –