[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: PDIC - Property Dependency Injection Container
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
chee
twin, я же тебе явно говорил, что запрещается внедрять новую зависимость в виде контейнера! Ты мог сделать внедрение конкретных зависимостей через конструктор, сеттеры или свойства, но ты внедряешь Service Locator

Пусть это и выглядит как массив. По сути твои зависимости запрашивают активно нужные для них зависимости по какому-то неведомому откуда-то взявшемуся ключу, тем и плох Service Locator. Во-первых(не так важно, но все же), не декларируешь интерфейсы входящих зависимостей, во-вторых (важно), классы запрашивают свои зависимостями, а не пассивно их ожидают. В-третьих(важно), ты пустил лапы контейнера во все классы приложения, попробуй те классы, что ты модифицировал завести под PHP DI, я сомневаюсь, что это будет легко.

Вообще почитай http://sergeyteplyakov.blogspot.com/2013/0...ce-locator.html.

Критиковать меня на протяжении уймы страниц и называть мой контейнер поделкой, когда твой контейнер не может внедрять зависимости без использования сервис локатора, ну это только ты можешь. blink.gif

Ладно это не столь важно, но показатель того как ты "хорошо" разбираешься в теме.



_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
chee
Цитата
'storage' => \SplObjectStorage::class,

Это можно было не делать, я тупанул, хотел сделать хранение в нем, потом передумал

Цитата (twin @ 14.01.2021 - 18:23)

Вообще конечно странная задача, я понимаю, что она заточена на твой контейнер

Вообще-то нет, эту задачу легко можно решить любым DIC, что Pimple, что PHP DI. Это типовой(обычный) код написанный с применение IoC принципов, за исключение способа внедрения зависимостей. У меня не было цели показать, что ты не сможешь это сделать, моя цель была в том что бы ты это смог сделать и получил опыт, который есть у меня.

Вот мой код https://pastebin.com/hAX2BuFe

Заметь, на сколько синтасически сильно раздута твоя карта зависимостей для контейнера, при том делается тоже самое (как минимум должно делаться). Видимо у тебя по-умолчанию нужно объявлять алиасы, потом говорить какой класс, а потом уже описывать зависимости. При том структура карты какая-то слишком непонятная. Зачем
Цитата
'Container' => true,
? Ты просто поместил скалярный тип в контейнер или это какая-та опция которая говорит контейнеру, что он может использовать свой объект в качестве зависимости, если да, то почему конфигурация контейнера в карте зависимостей находится? Объявление зависимостей и класс(в который они будут внедрены) в массиве никак не отличаются, это же непонятно. Также я не понял, где у тебя shared и not shared зависимости, в этом примере экземпляр класса фабрики должен быть создан только один раз, я из твоей карты не вижу каким образом ты фабрику делаешь shared?




_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
chee
А и кстати, я посмотрел https://pimple.symfony.com/, он тоже по умолчанию объявляет серсисы, а уже с помощью специального factory можно сделать фабричный сервсис. Я все еще, что-то не понимаю, или ты человек из моей подписи? Ты же даже не смог завести код под DIC контейнер по четко заданному ТЗ.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации
twin
Цитата (chee @ 14.01.2021 - 15:43)
twin, я же тебе явно говорил, что запрещается внедрять новую зависимость в виде контейнера! Ты мог сделать внедрение конкретных зависимостей через конструктор, сеттеры или свойства, но ты внедряешь Service Locator

Вот ты вывел гуся! Сам говорил, что не важно как их внедрять:
Цитата (chee @ 12.01.2021 - 07:23)
ты можешь использовать внедрение через конструкторы или объявить сеттеры для зависимостей, если тебе так противно внедрение через свойства, не суть.

Где тут про то, что нельзя локатор, пусть ты так это называешь?

Сначала говорил - "не суть", а теперь раздул скандал из этого. Я вообще на этом не заморачивался, меня и так устраивает. Хоть горшком назови.

Не вопрос сделать сеттеры, как два пальца. Цели такой не стояло.


Цитата (chee @ 14.01.2021 - 15:44)
Вот мой код https://pastebin.com/hAX2BuFe

Ну ты карту показал, а использовать то как? Где весь код? Я вот ничего не добавил не отнял. Конструкторы добавил только. А как твою фишку юзать?

Цитата (chee @ 14.01.2021 - 15:44)
моя цель была в том что бы ты это смог сделать и получил опыт, который есть у меня.

Ну да, чего уж там. В трех соснах не смог разобраться, опытный ты наш :D

То, что ты показал, можно один в один повторить и у меня, если ты не любишь алиасы. Вот так
    $injectionsMap = [	
\
Examples\Application::class => [
'actionBus' => \Examples\ActionBus::class,
'actionFactory' => \Examples\ActionFactory::class,
],
];



$container = (new \ABCDIC\Container)->setMaps($injectionsMap);
var_dump($container->get(\Examples\Application::class));


object(Examples\Application)#9 (2) {
["actionFactory":protected]=>
object(Examples\ActionFactory)#7 (1) {
["container"]=>
NULL
}
["actionBus":protected]=>
object(Examples\ActionBus)#6 (2) {
["storage"]=>
NULL
["actions":protected]=>
NULL
}
}



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



Насчет скаляра - да, это включается внутренний контейнер. У тебя он подрублен всегда, на сколько я помню, у меня опционально.

Давай полный код, тогда поговорим. Мне к своему коду добавить нечего, он и так работает. Ну а я пока сделаю сеттеры, раз ты так обиделся :D

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

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

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

user posted image
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.