Всем привет и с новым годом) Может кто подскажет, может есть

паттерн хороший или подход какой.

Суть вопроса: при старте программы создаётся куча всевозможных объектов. Многие из объектов завязаны друг на друга. То есть например объект А передается в конструктор объекта Б. Объект Б передается в конструктор объекта В и тд.

В результате есть достаточно большой и сложный спагетти код по созданию структур, необходимых для старта/работы программы.

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

Применить dependency injection - ок. Но меня смущает момент, который касается взаимосвязи объектов. В том плане что объект Б должен быть инициализирован никак не раньше объекта А и тд. То есть я вот раздумываю над тем как можно снять с программиста обязанность думать об этих деталях.

Грубо говоря, программист декларативно задаёт все что нужно для работы объекта его класса, а уже сам объект должен создаться автоматически и в нужный момент.

Как лучше к этому всему подступиться?

Нужно начать уменьшать связанность. Сперва вынесите объекты из конструктора в сеторы. Не передавайте объекты, передавайте структуры. А затем можно будет значения подгружать из глобального словаря.

Imho классический SOLID. Как минимум: 1. Продумать, спроектировать и объявить абстракции (например интерфейсы зависящие только от других интерфейсов и ни в коем случае от объектов). 2. Продумать как используя абстракции п.1 будете реализовывать юнит-тестирование. В идеале написать эти самые юнит тесты :). 3. Перепроектировать реализации, избавиться от зависимостей от других реализаций - перейти к поддержке реализациями только абстракций п.1, зависящих только от других абстракций (классы должны реализовывать интерфейсы п.1 и не должны зависеть от других классов). 4. Внедрить DI (например Spring4D). В части "а уже сам объект должен создаться автоматически и в нужный момент" - DI поддерживает разные паттерны (в т.ч. одиночку, фабрику и т.п.). Вы например в секции инициализации юнита регаете конкретную реализацию с необходимым в данном случае паттерном для конкретной абстракции (можете даже имя для этой сущности в контейнере приписать), а все зависимости резолвите через контейнер (явными вызовами или аноташками). Возможны исключения зависящие от предметной области, когда для кода важен порядок создания сущностей (скорее всего это будут синглетоны), тогда в отдельном модуле/объекте/методе просто предварительно однократно резолвите их в нужном вам порядке. В итоге просто в проект "накидываете" нужные вам юниты, они сами регаются в DI контейнере и резолвятся по необходимости. Т.о. вы в "боевой" проект включаете реальные реализации, а в демо проект включаете эмуляцию какого-то функционала, а в проект с юнит тестами моки абстракций. В результате нет связанности, условной компиляции и многих других какашек, которые скорее всего вас сейчас настораживают.