Скажите пожаулйста DTO иммутабельны?

Скажите пожаулйста DTO иммутабельны?

нет, dto это массив на тестостероне

То есть нужно каждый раз новый дто делать, или можно внутри нарисовать метод changeValue

или еще проще, на прямую менять

$dto->value1 = 'test';

@arturpanteleev если массив на тестостероне, тогда изменение делать на прямую

нет смысла лепить доп методы

@arturpanteleev если массив на тестостероне, тогда изменение делать на прямую

есть такая точка зрения

тут сетеры чисто для того чтобы примитивную валидацию сделать

аааа, сеттеры когда валидируем

спасибо

Есть какие-нибудь веские аргументы не юзать Service Locator? если человек не пишет юнит-тесты и не переносит классы из проекта в проект... то ему ведь не обьяснишь чем оно плохо.

Есть какие-нибудь веские аргументы не юзать Service Locator? если человек не пишет юнит-тесты и не переносит классы из проекта в проект... то ему ведь не обьяснишь чем оно плохо.

а чем оно плохо?)

все говорят плохо :) я уже даже и поверил. и не юзаю. а тут я рраз и задумался. а чем? :)

все говорят плохо :) я уже даже и поверил. и не юзаю. а тут я рраз и задумался. а чем? :)

ну вот подумай)

ну мне то юниттесты писать иногда надо.

и потом взвешивай плюсы, минусы, и есть ли разница в контексте того что ты описал

очень легко вытрезвляет. но мало кто пишет...

ну мне то юниттесты писать иногда надо.

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

так-то сервис локатор с тестами не сильно полезен)

с юнит-тестами да

тесты дурацкие получаются. неправильные.

с интеграционными норм

тесты дурацкие получаются. неправильные.

ты можешь на моки подменять все... если нормальный локатор

мокаешь сервис в SL и погнали

пример нормальных локаторов можешь подсмотреть в Laravel (если под php)

В Yii2 по другому никак

ты можешь на моки подменять все... если нормальный локатор

нол ведь надо знать что надо мочить!

нол ведь надо знать что надо мочить!

а так типа не надо знать?

да, менее явно, да менее удобно....

да, глобальный доступ к зависимостям

да, в неумелых руках можно в шаблонах каких видеть Database::query("SELECT ...")

но в легаси проекте который написан через жопу это может быть спасением. Ибо на DI ты быстро все не переведешь. А тут можно будет постепенно

да. я как раз про ларавел. у них там вообще прикольно в плане тестинга. вот именно.

$this->assertDatabaseHas($table, array $data);

У сервис локатора ИМХО самый большой недостаток такой же, как и в симфони, когда было нормой сервисы делать публичными и не было автовайринга

$this->assertSoftDeleted($table, array $data);

У сервис локатора ИМХО самый большой недостаток такой же, как и в симфони, когда было нормой сервисы делать публичными и не было автовайринга

автовайринг непричем. И без него жить можно. А вот отсутствие ограничений, лень разработчиков и желание запихнуть контейнер в любую дырку.... вот да... это похуже чем то что в ларавель

ну собственно автовайринг и приватные сервисы + сказка что за счет инлайнинга быстрее будет сильно сказывается на умах тех кому пофигу

автовайринг непричем. И без него жить можно. А вот отсутствие ограничений, лень разработчиков и желание запихнуть контейнер в любую дырку.... вот да... это похуже чем то что в ларавель

Я не про автовайринг, а про времена, когда его не было)

Я не про автовайринг, а про времена, когда его не было)

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

в чем проблема?

в том что ты задаешь такой вопрос))) ну мол.... довольно просто объяснить чем плохо инджектить контейнер, а вот почему структура проекта важна, что такое cohesion, почему не стоит ложить файлики по папочкам по типу (репозитории сюда, контроллеры сюда, сущности сюда, и еще утилиты сделаем потому что лень) намного сложнее)

попробуешь?

"довольно просто объяснить чем плохо инджектить контейнер" - так ты так и не обьяснил! :)

попробуешь?

не, если интересно - почитай про типы cohesion-а

и что там зачем и причем тут coupling

"довольно просто объяснить чем плохо инджектить контейнер" - так ты так и не обьяснил! :)

Зависимости не объявлены в контракте класса, т.е. неочевидны и непредсказуемы

Зависимости не объявлены в контракте класса, т.е. неочевидны и непредсказуемы

да. для меня это очевидно плохо. а тому кто не пишет юниттесты? работает же!

да. для меня это очевидно плохо. а тому кто не пишет юниттесты? работает же!

find usage.

так оно найдет.

ну блин, тем кому пофиг - им так и будет пофиг)

все эти загоны они как бы не про маленькие проекты на одного человека....

в сишарпе - найдет. в php - тоже. если в ларке заюзан ide-helper

а хотя бы на проекты на одного человека где есть мечты "выстрелить" и стать проектом хотя бы человек на 50

в сишарпе - найдет. в php - тоже. если в ларке заюзан ide-helper

если

ну и повторюсь - в ларке более-менее

в симфони когда инджектиться весь контейнер и там были айдишки сервисов foo.bar.baz - чет как-то даже find usage не поможет

даже с symfony плагином

да для любого Yii тоже можно наверняка нагенерить meta для шторма

да для любого Yii тоже можно наверняка нагенерить meta для шторма

можно)

это все про связанность и зацепление. Вот это все. Если ты с этими концепциями не разбирался - сложно объяснять.

в юи принято наследоваться от СЛ, чтобы понаписать докблоков на магические свойства

или ложить фейк-файл с СЛ с докблоками

совет от главного мейнтейнера юи

совет от главного мейнтейнера юи

от Макарова? или китайца? :)

от самдарка, щас китаец не при делах)

с сервеис локатором нет проблем см import в python/js. Но есть ограничение в виде того, что локатор не знает кому он отдает зависимость, т.е. нельзя раздать за одним сервисом разные реализации, как в случае инъекции(развернутой стрелочки)

с сервеис локатором нет проблем см import в python/js. Но есть ограничение в виде того, что локатор не знает кому он отдает зависимость, т.е. нельзя раздать за одним сервисом разные реализации, как в случае инъекции(развернутой стрелочки)

Т.е. IoC в SL не реализуем?)

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

ну для этого надо выкручивать какие-то хитрые штуки, в случае нативных импортов вроде бы нет

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

когда они разные))

Т.е. IoC в SL не реализуем?)

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

а вот инверсия зависимости с SL может быть только за счет какого-то промежуточного модуля который уже занимается подменой реализации (вот примерно как в Laravel)

"довольно просто объяснить чем плохо инджектить контейнер" - так ты так и не обьяснил! :)

1. Даем классу доступ ко всем сервисам проекта, тем самым потенциально убиваем инкапсуляцию(правда это решается созданием нескольких ограниченных сервис локаторов в рамках модуля) 2. Клиентский код получает ненужные знания об инфраструктуре(код сервиса) 3. Неявные зависимости класса 4. Отсутсвие строгой типизации для пробрасываемых сервисов

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

Например интерфейс Notification - в каком то случае должен слать на почту, в каком то пуш, в кком то смс

Или логер, даже более частый пример

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

Например у тебя класс зависим от контракта кэша PSR-6, и ему по барабану где этот кэш крутится - redis, db, files, да хоть на луну голубями кэш складывай. Главное твой класс с зависимостью от интерфейса кэшера сможет ложить туда кэш.

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

когда нужны разные реализации, декорация и т.д. это все про open/close и srp, сильно коррелируется.

а ты можешь реализацию хоть в рантайме менять

ааа. ну декорация то понятно. это очевидно

проще всего это все воспринимать как "работает - не трогай" и когда хочешь расширить поведение - за счет композиции/агрегации уже мутить

просто я видел что в сишарпе когда просишь зависимость в конструкторе то можно аттрибутом попросить себе чтото особенное :) и вот задумался - а зачем. класс то сам не должен знать

просто я видел что в сишарпе когда просишь зависимость в конструкторе то можно аттрибутом попросить себе чтото особенное :) и вот задумался - а зачем. класс то сам не должен знать

атрибут он как бы сверху, метаданные. потому можно

так то да. но в каких случаях. если сверху, то правильнее все-таки в конфигураторе контейнера решать.. а не тут

так то да. но в каких случаях. если сверху, то правильнее все-таки в конфигураторе контейнера решать.. а не тут

как удобно. В PHP у тебя нет атрибутов и у тебя выбор - кастыли с docblock или внешний конфиг. Еще важный момент - это бывает что модуль не должен вообще заморачиваться (не твое не трогай)

это все к вопросом кто за что отвечает и кому что принадлежит (и какие файлы ты при каких ситуациях хочешь трогать а какие нет)