Ты это привел в пример, так чего же делаешь с точностью до наоборот?

Какого фига у тебя объекты зависят друг от друга?

Ты погнался за дешивизною:

Но не удосужился разобраться, почему так. И недодумал, что может случиться, если так опрометчиво поступить. Так что это:

не совсем соответствует действительности. Это сборник недостатков вышеперечисленных паттернов, не более того.

PS Если приводишь к PSR-11, поправь и это место

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

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

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

Ни чем, так как ты не разобрался. Объяви карту зависимостей так

   $injectionsMap = [
        'ExampleA' => [
            'exampleB' => '*ExampleB',
        ],
		
        'ExampleB' => [
            'exampleB' => 'ExampleB',
        ],
    ];

если хочешь что бы зависимость у exampleB у объекта ExampleA была not shared

вот сейчас переводил CMS на соответствие psr-15

    'ExampleCMS\Application' => array(
        'metadata' => ExampleCMS\Metadata::class,
        'middlewareFactory' => \ExampleCMS\Factory\Middleware::class,
        'response' => '*' . Laminas\Diactoros\Response::class,
    ),

таким образом внедрил пустой response, он мне нафиг не нужен как shared в контейнере, потому я его объявляю как non shared, при этом метаданные и фабрика мидлваров мне нужны как shared.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Я не понимаю, как они у меня зависят друг от друга? То что ты внедрил shared зависимость как shared и ожидаешь not shared поведения это не проблема моего контейнера, скорее это проблема документации к нему

я так понимаю, это вывод основан опять же на твоем недопонимании функциональности контейнера (я про то что ты объявляешь not shared зависимость как shared, и ожидаешь not shared поведения у объектов)

Я думал об этом, может поправлю.

ABC-Framework сборник недостатков паттернов, нравится? А по существу?

Для начало дай определение термина DIC в твоем понимани?
Затем объясни почему паттерны, которые инкапсулированы в контейнере, вдруг стали плохими? Объективно почему регистр тут вдруг плох? он же только в контейнере, его лапки не торчат из всех щелей приложения.
Почему билдер тут стал плохим? он же создает объекты и настраивает их. Он делает этого не "блестяще" что ли или как?
Почему всего лищь возможность дать использовать сервис локатор стала недостатком?
Почему наличие медиатора стало недостатком?

так и хочется спросить https://www.youtube.com/watch?v=UrpSiFPY-Mg

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

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

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

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

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

2. Я не говорил, что реестр (не регистр) плох. Но у любого паттерна есть недостатки. Так вот просто ты взял худшее из него. Кстати, ради справедливости нужно сказать, что это не реестр вовсе. Реестр хранит однотипные объекты. То, что используется в DIC, это просто хранилище (storage). Это больше похоже на Pull, хотя в PHP его сложно реализовать.

Впрочем не суть важно, как это называется, важно как это используется. Ты в свем "реестре" хранишь не только "снаряженные" сервисы, но и сырые объекты зависимостей. Пусть даже ты там что то намутил со звездочкой. Сама практика хранения объектов зависимости уже порочна.

Ну и внешние объекты, это песня конечно))) У них вообще нет никакой возможности не быть расшареными.

Дело в том, что сервис, который строится посредством DIC, должен быть агрегатом. А у тебя там композиция. В этом и ошибка. Так что не сам паттерн "реестр" плох, а плохо его никудышнее использование.

3. Тоже самое и с билдером. Я тоже ничего против него не имею. Но реализация... Через публичные свойства... Ладно, не буду по больному.

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

Назвал ты его DIC, но это... там... ну можно немножко... почему бы и нет...
Нельзя быть беременной наполовину.

5. Про медиатор я вообще ничего не говорил, ибо не понимал, зачем он. Теперь понимаю. Он нужен, чтобы исправлять косяки с публичными свойствами. Ну так потому и не понимал, что не сталкивался с такой проблемой.

Ну вот как то так, если по существу.

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

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

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