просто подправить сгенерированные

заодно люди смогут инглиш учить

потому что есть мысль что перевод сделает больше плохого)

Кстати, да. На самом деле, сейчас субтитры невероятно хорошо на английском генерятся, я недавно забыл выключить и удивился

на самом деле я хз, может быть имеет смысл сделать нормальные субтитры на инглише

ну если 100% сможешь донести контекст

Речь Мартина сложно переводить, имхо

Приведи какие то конкретные примеры, более менее нормальное обьяснение с вики, откуда я взял эти картинки, всё остальное какой то cryptic shit

https://martinfowler.com/articles/injection.html

лучше этого как по мне ничего нет

Речь Мартина сложно переводить, имхо

я пробовал - в целом субтитры убивают красоту

лучше этого как по мне ничего нет

Это я читал относительно давно уже, нужно обновить, кстати вроде он там писал что service locator антипаттерн

Это я читал относительно давно уже, нужно обновить, кстати вроде он там писал что service locator антипаттерн

не совсем. Он там очень подробно описывает разницу и чем плохи сервис локатора

антипаттерн же - это когда у тебя сервис локатор позволяет вытащить вообще любую зависимость

ну то есть у тебя есть "контейнер" и ты из него что-то достаешь.

вот это типа не очень хорошо

а если у тебя локаторы на каждый тип свои - то тогда как бы и норм

вот это типа не очень хорошо

Ну допустим этот локатор инжектится в конструктор, а потом класс вытягивает из него свои зависимости, это плохо Мало того что в класс, если он правильный и соответствует high cohesion принципу инжектится вообще что то непонятное, т.к. еще то что инжектится может и не иметь внутри того что нужно этому классу т.к. контракт не определён. Сервис локатор позволяет вытащить любую зависимость, т.е. любой инстанс любого класса. Что то вроде умного оператора new.

Сервис локатор это DI контейнер на выворот

а ты почитай

сервис локатор не совсем так должен работать если что

> соответствует high cohesion принципу тут вопрос в coupling а не в cohesion

> соответствует high cohesion принципу тут вопрос в coupling а не в cohesion

ну допустим есть нормальный класс MovieImpl и он привязан к какому то ServiceLocator, т.е. coupling вроде бы нормального класса с хорошим cohesion к непонятно чему.

чего ты к кохижену привязался? ты не знаешь хороший он или плохой тут

оно тут вообще н причем

MovieImpl не привязан к сервис локатору

там есть жирный абзац

Service Locator vs Dependency Injection

читай его если хочешь

tl;dr - представь что ты попал на 10 лет назад и нормальных контейнеров зависимостей мало

сергей vs сергей

я вообще заметил сколько людей столько и мнений)

я вообще заметил сколько людей столько и мнений)

большинство мнений не имеет под собой доказательной базы

Service Locator vs Dependency Injection

Ну так я всё правильно написал, класс имеет зависимость на локатор The key difference is that with a Service Locator every user of a service has a dependency to the locator.

With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.

т.е. всё верно, классу которому нужен какой либо сервис вообще не зачем знать о локаторе. И если бы это был один класс, этот локатор будет в каждом классе которому нужны будут зависимости.

но если будет по локатору на тип - то не страшно

другой вопрос что сегодня в этом не то что бы много смысла

но если будет по локатору на тип - то не страшно

Всё равно как то хреново, если классу нужно 3 зависимости то лучше их в конструкторе передать чем локатор, если больше то может стоит рефакторить класс, но это нужен конкретный пример чтобы решать.

Всё равно как то хреново, если классу нужно 3 зависимости то лучше их в конструкторе передать чем локатор, если больше то может стоит рефакторить класс, но это нужен конкретный пример чтобы решать.

зайди к проблеме с другой стороны

представь что внезапно не существует ни одного контейнера зависимостей

и у тебя выбор - сервис локаторы, фабрики или писать свой DI контейнер

другой вопрос что сегодня в этом не то что бы много смысла

Сейчас куча нормальных контейнеров, на момент написания статьи 2004 г. их не было вообще. На сайте mvnrepository по крайней мере самый старший который нашёл 2005г. и то версия 0.0.1 alpha.

Сейчас куча нормальных контейнеров, на момент написания статьи 2004 г. их не было вообще. На сайте mvnrepository по крайней мере самый старший который нашёл 2005г. и то версия 0.0.1 alpha.

ну вот я об этом и говорю, вопрос как это все на время ложится

с точки зрения сложность реализации service locator очень простая штука

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

еще возможный кейс сегодня для SL - это рефакторинг какого-нибудь дикого легаси

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

ну хз можно простую штуку сделать сложной)

и никто не поймет)

ну хз можно простую штуку сделать сложной)

можно запихнуть лампочку в рот, но зачем?

но вообще да согласен сейчас в том же пхп полно всяких реализаций контейнеров

на самом деле их не то что бы много. штуки 4-5 толковых и интересных. Все остальное - калька. Если брать другие языки - ситуация схожая. Для Js вон до сих пор ничего нет.

Ето(легаси) - как раз таки подходящий клиент для SL, так как он поддерживает точечное внедрение а DI нет

о я сегодня по стримил видео на тему наследование композиция, агрегация

есть желание по унижать, в пхп)

там мое имхо)

завтра гляну

меня сейчас больше волнует вопрос - мне нужны задачки на тему тестирования

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

что-то более приближенное к реальности

ну не юнит тестами едины

не стоит на них зацикливаться

есть и другие а задачки это рефакторинг

зацикливаться никто не планирует, но первый уровень пирамиды тестирования надо покрыть

начинаешь ценить тесты в момент рефакторинга

и если интеграционные тесты писать изи-бризи, то с юнитами у людей проблемы

твой 1 уровень это юнит тесты?

твой 1 уровень это юнит тесты?

а есть какой-то другой?

ERROR: S client not available

юнит тесты -> компонентные тесты -> интеграционные -> e2e

ну я к тому что если проект есть, то начинать с автотестов сложновато

и если интеграционные тесты писать изи-бризи, то с юнитами у людей проблемы

потому что они пишут тесты к существующему коду?

ну я к тому что если проект есть, то начинать с автотестов сложновато

допустим нет проекта

с автотестов в виде юнитов

потому что они пишут тесты к существующему коду?

и это тоже

я к тому что проект проще покрывать приемочными

и потом только впихивать юнит

проще != лучше

меня сейчас больше волнует вопрос - мне нужны задачки на тему тестирования

тогда тебе нужно рассказать про tdd

и потом только впихивать юнит

нет

тогда тебе нужно рассказать про tdd

да нет никаких проблем с тем что бы рассказать что-то или объяснить

мне нужны примеры... ну типа задачки

мол "давайте по быстрому напишем функционал заказа такси в убер"

НОрм задачка

и потом только впихивать юнит

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

мол "давайте по быстрому напишем функционал заказа такси в убер"

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

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

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

как раз на декомпозицию

Мне было сложнее, так как у нас ни убера, ни яндекс.такси. Я чот даже не очень представляю как там вглядить функционал заказа)

В смысле - постановка задачи именно так смутила бы)

ну предметную область и логику я объясню тем кто не каждый день на уберах разъезжает

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

юнит тесты заставляют контролить зависимости

а уже от туда норм декомпозиция

юнит тесты заставляют контролить зависимости

не совсем.

ну то есть как по мне это все побочные эффекты

основная идея - смотреть на код с точки зрения клиентского кода

количество зависимостей - это просто неудобно

идея же в проектировании контракта

юнит тесты заставляют контролить зависимости

юнит тесты это часть tdd процесса, т.е. разработки направляемой тестированием. Tdd не даёт писать плохой код, по крайней мере подсказывает что что то идёт не так когда тесты становится трудно писать.

не количество

не количество

поясни мысль более явно