Нет, я просто уточнил, понимаешь ты это или нет. Потому что очень многие не понимают различия, от того и неверно используют паттерны.

Затем, что ты написал это:

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

Я имею ввиду то, что очень часто контейнер представляется как объект, который можно передать в какой то другой объект, а в нем уже достать то, что нужно. Другими словами, DIC с глобальным доступом, это Service Locator/ Попозже пример напишу. DIC можно передать параметром, но только в Composition Root, либо в точку сборки какого то отдельного модуля. Никак не ниже.

Сервисом в текущем контексте обычно называют объект, использующий другие, вспомогательные объекты. Зависимости. При существующих реализациях DIC есть большой соблазн напихать в него все подряд, а потом доставать нужные сервисы по ключу. Я давно не смотрел Slim, раньше там это было основой. С одной стороны удобно, с другой это получается реестр (Registry). Контейнер в моем понимании отвечает за конкретный сервис (ну или тематически связанную группу сервисов). И для прозрачности кода лучше иметь несколько экземпляров контейнера, чем одну большую мешанину.

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

Именно это и хотел сказать. Ну чуть позже покажу на примере.

С чувством юмора проблемы? Хорошо, учту твою ранимую душу)))

Согласен. Твое мнение имеет право на жизнь, читай мою подпись)))

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

Итак, минусы твоей концепции:
1. Потеря прозрачности кода. Зависимости внедряются куда угодно по иерархии классов. В родителей и даже трейты. Ищи-свищи.
2. Опасность нарушения инвариантности.
3. Нарушение принципа SOLID

И это никак не решается.

Минусы конструктора:
1. Опасность "телескопического конструктора". Решается с помощью DTO.
2. Нужен маппинг. Но это вовсе не недостаток, это очень полезный паттерн. С кучей профита. Написав его один раз, можно долго пожинать вкусные плоды.
3. Про необязательные параметры, это мимо. Ничего не стоит сделать их обязательными. Даже с DTO.

Вот и весь объективизм.

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

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.