Service Locator и Branch By Abstraction — супер-зелье

[@lair]

Почему сервис-локатор, а не dependency injection?

[@PaulBardack]

Наверное вы имеете в виду dependency injection container, так как di это всего лишь инъекция зависимости. А так, вы можете использовать оба паттерна. Я выбираю сервис-локатор, чтобы в любом месте можно было получить доступ к требуемому объекту, не нагружая конструктор. Хотя с этим можно поспорить.

[@lair]

Наверное вы имеете в виду dependency injection containe

Нет, я имею в виду Dependency Injection как паттерн (в противовес Service Locator как паттерну).

Я выбираю сервис-локатор, чтобы в любом месте можно было получить доступ к требуемому объекту, не нагружая конструктор.

Вы понимаете, что таким образом ваш код получает (а) множество прямых зависимостей от сервис-локатора и (б) невозможность определить по контракту класса, от чего тот зависит?

Ну и да, использовать в сервис-локаторе строковые ключи — плохая идея, в норме используются типы интерфейсов.

[@PaulBardack]

Да, понимаю. Скажем так, статье не о пользе/вреде использования di или сервис-локатора. Потому не хотелось бы здесь разводить об этом спор. Если же обойтись без использования сервис локатора, тогда кто будет отвечать за зависимости в коде? С одним di подмена одного класса на другой может привести к изменениям в разных местах, что усложняет, а то и вообще сводит на нет удобство branch by abstraction

[@lair]

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

Если заменить сервис-локатор на вбрасывание зависимостей, то за зависимости будет отвечать вбрасывающая система. У Симана все это прекрасно описано.

С одним di подмена одного класса на другой может привести к изменениям в разных местах

Да нет же. Вы и так, и так конфигурите некий composition root, задавая соответствие интерфейса и реализации, просто в сервис-локаторе вы потом достаете зависимости сам явно, а в dependency injection их в вас вбрасывает внешняя система.

[@PaulBardack]

В таком случае — да. Для исключения путаницы, то что вы описали я называю DIC

[@lair]

Dependency Injection — устоявшийся термин. И для этого не обязательно нужен контейнер.

[@sAntee]

Какой путаницы? Dependency Injection он и в Африке DI. Можно инжектить в конструктор, а можно в объект. С другой стороны, и Service Locator, и DI являются реализациями Dependency Inversion принципа (последняя буква solid). И вот тут уже путать не надо. DI, в отличае от Service Locator'а, как минимум позволяет а) абстрагироваться от контейнера б) отдать управление жизненым циклом объектов на аутсорс. Если и есть в этом мире антипаттерны, то это классический синглтон, и Service Locator.

[@tenbits]

А как быть, если разрабатываются две(+n) раздельные фичи для класса `Foo` и в конфигурации у нас свойства: `enableFooFeatureА` и `enableFooFeatureB`?

[@lair]

Две раздельные фичи в одном классе — нарушение SRP, не делайте так.

[@tenbits]

) Да я так и не делаю. Просто ведь из примера — мы добавляем некий функционал к уже существующему классу, то-есть расширяем его. И это вас не смущает? А если мы хотим разбить этот функционал просто на два флага, это уже вас смущает? Или же мы делаем два расширения по очереди, это вас тоже не смущает, а вот уже параллельно, это уже не комильфо?
Вообщем о single resp. principle можно долго холиварить, но не в этом суть. Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.

[@lair]

Суть вопроса, или по данной технике можно лишь одну фичу за раз добавлять в `Foo`.

Можно сколько угодно. Branch By Abstraction — частный случай Feature Hiding, который позволяет регулировать фичи не только путем подмены реализации, но и просто вставкой if-ов в код.

[@PaulBardack]

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

[@PaulBardack]

Выше уже ответили. Это плохая практика.

[@tenbits]

> Появляется задача изменить работу doBaz() и добавить новый метод doGood()

А как быть если для изменения `doBaz` и для нового метода `doGood` нам нужно 2 Флага?

[@PaulBardack]

Внедрите в таком случае флаг на уровне метода в самом классе.

[@wheercool]

[offtopic]Прочтение статьи навеяло [/offtopic]

[@garex]

Мне кажется или кто-то не умеет готовить `git flow` и организовать организацию?

Настораживает, когда проблемы инфраструктуры решают в коде, а проблемы кода — в триггерах БД ))

[@PaulBardack]

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

[@garex]

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

Претензия здесь не к тактике/методу/способу, а к стратегии.

Ужасы merge'й обычно бывают у веток, которые никто не ребэйзит и у которых миллион «merge feature branch into feature branch from origin:feature branch». Если же всем (контроль — задача лидера) соблюдать банальное правило, что фича-ветка всегда отребейжена на свежий местный develop, то проблем с merge ноль, ибо уже все отребейжено.

[@PaulBardack]

Ок, а как быть, если вам нужна фича, которую делает другой программист, но которой еще нет в dev? Допустим, что это большой функционал, а у вас нет времени ждать, пока он будет закончен — вы можете начать параллельно.

[@garex]

Дык работаете в одной фича-ветке?

Либо в третью ветку скидываете интерфейс и класс-заглушку (это уже ближе к вашему варианту), но не «засоряете» этим trunk/dev/master/develop/yourname.

Открою тайну — любая VCS умеет делать ветку от любой другой ветки.

[@PaulBardack]

Ну вот и начинается. Ветка от ветки, затем оказывается, что это еще нужно кому-то и он еще больше ветвится. А если у вас начинает работать 20 человек, в итоге кол-во веток лично меня начинает страшно напрягать.

С засорением проекта не спорю — становится много чего. Но зато у каждого есть актуальный код и в тоже время стабильный trunk.

[@garex]

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

Дык их публиковать то не надо сразу всем подряд и чистить за собой надо тоже.
Локально у человека обычно 3 ветки — develop, master, feature/bla.

А вот вопрос возникает, что когда у нас слишком многим нужно паралелльно, что-то — почему оно так? Low coupling/high cohesion м.б. нужен? Хотя это больше мечты ))

Приведите реальный пример, когда нескольким людям что-то надо было, м.б. даже с картинкой. Сколько людей зависело? 1/2/4/8/...? Как это оно так получилось?

[@PaulBardack]

Локально да, а когда нужно каждую ветку протестировать — pull request. Вот тут они и будут копиться, в зависимости как быстро они успешно проходят тесты и как скоро и ревьювят.

Пример: разработка бекенда со сложной обработкой ссылок (парсим, категоризируем текст, картинки пережимаем, тэгаем и т.д.)
Параллельно пишется для этого апи, которого тоже много. Апи должно быть актуальным, и максимально быстро выкатываться с фичами.

[@shuron]

тут вопрос на сколько у вас быстро изменения идут в продакшн.
Я готово поспорить что те кто постоянно «бранжит» не готовы релизить несколько раз в день в продакшн в принципе.
А иногда и один раз в день сложно…
И это леко понять… Мердж — мануальный таск… не автоматизировать.

[@garex]

Релизить несколько раз в день? Это по-мойму ближе к хотфиксам. Каждый день так делаем, после сложного релиза или когда ВНЕЗАПНО (с) надо что-то кому-то где-то.

`git flow hotfix start x.y.z`

За мердж фича-веток надо отпиливать по одному пальцу. Фича-ветки должны только ребейзиться на девелоп — и только после этого вся красота и польза веток начинает быть видна в истории. А когда куча веток начавшихся где-то глубоко внизу под текущей версией девелопа, в которые девелоп ещё и вливается каждый раз… Это уже бессмысленый набор коммитов, а не ветки ((

По одному пальцу, не меньше.

PS: shuron, скорее всего у вас тоже организация и дисциплина хромает. Как только мы ввели у себя «китайский» подход — всё сразу наладилось ))

[@shuron]

2012 Фейсбук уже два раз в день может
Хотя они лохи.
Амазон оже 2011-ом кажды 11.6 секунд что-то в продакшн релизил techcrunch.com/2012/08/03/facebook-doubles-release-speed-will-roll-new-code-twice-a-day

А у нас не все ок, пока но лучше чем год назад, когда я перешел в компанию…

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

Соседняй команда состоит из 5 девелоперов и они бранжат… Счастье если они раз в неделю релизнутся…

[@PaulBardack]

Почему может быть только вариант с корявой дисциплиной и кривой организацией?
Как на счет удобства A/B тестирования на определенном проценте пользователей?
Про скорость релизов выше тоже привели пример