Совершенно верно, поэтому я и написал, что это «выходит за рамки данной статьи». Два DI — это Dependency Inversion и Dependency Injection, два понятия, которые путают так же, как и Dependency Injection и Inversion of Control. Цель статьи — дать понимание, что мы используем Dependency Inversion, чтобы разделить модули асбтракцией, Dependency Injection, чтобы избавиться от инстантинации вручную, а реализуем это посредством фреймворка, построенного по принципу Inversion of Control. И ничто из этого не является синонимом друг друга.
Этот пример здесь уместен исключительно в контексте предшествующих примеров, где в конструкторах происходила инстантинация. Тут же наглядно видно, что инстантинация пропала из списка обязанностей класса Foo.
С тем маленьким нюансом, что изначально слой с А зависел от слоя с B, а после введения IB уже слой с B стал зависеть от слоя с А. Таким образом мы не разрываем полностью связь между слоями, а лишь ослабляем ее и меняем направление, получая слабое зацепление. В результате получается подобная штука — https://habrahabr.ru/post/269589/
Понятие владения исключительно абстрактное. А про сборки посмотрите того же Мартина, у него есть обширная теоретическая база на эту тему в «Принципах, паттернах и методиках гибкой разработки на языке C#».
IoC это собственно и есть способ реализовать ваши слои независимыми друг от друга
Чтобы сделать слои независимыми друг от друга, надо разорвать связь, т.е. убрать ссылку на класс B из класса A вообще :) Но это не в наших интересах, т.к. тогда приложение не сможет выполнять свои функции. В наших интересах эту связь ослабить, а делается это путем введения промежуточной абстракции (интерфейса или абстрактного класса). Понадобиться это может, если мы захотим, например, протестировать класс A изолированно от класса B (тогда мы заменим B фэйковой реализацией (моком) и подсунем его A). Или если мы предполагаем, что в дальнейшем мы можем использовать в системе другую реализацию B, но при этом не хотим, чтобы изменения вообще хоть как-то касались класса А. А вот как мы собираемся инстанцировать класс B — это уже вопрос отдельный, и именно при ответе на него и появляются фабрики, сервис локаторы и депенденси инжекшены.
Тогда, когда можно, грубо говоря, «один раз сконфигурировать и забыть», избавившись таким образом от написания оператора new или вызовов Service Locator'а каждый раз, когда вам нужен экземпляр класса, на который указывает зависимость. Здесь, скорее, стоит вопрос, когда надо использовать инверсию зависимостей, а когда нет, а это отдельная большая тема для дискуссий.
В таком случае, как мне кажется, механизм «фоновой» инстантинации, которую предлагает DI, вам просто не подходит. Наличие DI-фреймворка в системе не означает же, что вообще ВСЕ зависимости надо прогонять через него. В вашем инструментарии всегда есть те же фабрики и фабричные методы, если нужно инкапсулировать инстантинацию в одном месте, но при этом клиентский код должен ее контролировать.
Нелогично. Интерфейс, на то и интерфейс, что им никто не владеет, а он просто описывает абстракцию или какую то общую идею. Почему кто-то кем-то должен владеть то?
Такова была идея автора этого принципа — Роберта Мартина. Если эту идею игнорировать, то вообще непонятно, что за инверсия там имеется в виду. В общем-то это чистая условность.
но зависит от ServiceLocator, от которого таким образом начинает зависеть буквально каждый метод, а значит переиспользовать код, не переиспользовав ServiceLocator — невозможно
Совершенно верно, а еще зависимость от IBar/IServer так и остается для клиента класса Foo неявной.
Метрики — это измерение чего-либо с целью понимания ситуации путем сравнения. Мерить и понимать вы можете что угодно и где угодно. Можете мерить кол-во строк кода, кол-во регрессий, велосити команды, etc. Какая разница, водопад там или нет.
Скрам поможет вам понять на ранних этапах, что вы не успеваете в свой фиксед прайс. После первого же спринта у вас разработчики собираются на ретро и начинают ныть, что не успели полбэклога они потому, что постоянно меняли одни и те же файлы все вместе, из-за чего уходила тонна времени на слияние. Скрам заставляет их не молчать в тряпочку, не дуться втихую на Васю и не обсуждать эти проблемы только с Петей на перекуре, потому что остальные «ну дебиииилы», а говорить об этом открыто. Задача SM'а не дать скатиться этому в базар. И если он со своей задачей справится и поможет команде самоорганизоваться, т.е. самой поднимать проблемы, обсуждать их и находить решения, то есть все шансы вернуться на нужные рельсы и таки успеть фиксед прайс в срок. В данном конкретном примере, команда имела бы все шансы решить, что им срочно нужно в систему контроля версий, иначе кердык.
Водопад — это процесс разработки, поэтому влияет напрямую. В ванильном водопаде, например, нельзя проектировать, когда пошел уже этап конструирования. Ну вот нельзя и все. Соответственно про TDD, например, как про инженерную практику можно забыть. Скрам, как ниже правильно отметил ApeCoder, — это не процесс, это организационно-коммуникационный фреймворк, который про то, как заставить всех общаться в ключе выявления изъянов в процессе, который может быть любым (даже водопадом при некоторых допущениях).
«Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: „Хочу большой корабль, способный бороздить бескрайние, чёрные глубины.“ Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.»
Ответом на это является инкрементность и итеративность. Клиент приходит, рассказывает сказки, через равные интервалы видит результат, вносит коррективы и так по кругу. Внимание, вопрос: где тут Скрам? Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность через механизм спринтов. Но суть в том, что самих по себе их достаточно для обеспечения того, что вы описываете, и Скрам тут — ни к селу, ни к городу. Другое дело, если бы вы говорили, что инкрементности и итеративности может быть недостаточно для обеспечения надлежащего качества/объема работ или попадания в сроки при заданном бюджете. Вот тогда можно было бы говорить о Скраме как об инструменте, с помощью которого можно понять, где есть проблемы (на стороне PO, на стороне команды или и там, и там), которые снижают оные показатели. Еще раз — лакмус.
Потому что водопад прост, как пять копеек. С точки зрения понятности процесса, понятное дело. Вокруг аджайла и скрама же молодые и перспективные, как здесь справедливо уже было замечено, выстроили целый ритуальный культ. Вы вот заметили, что ни в этой статье, ни в статье, на которую эта статья ссылается, по факту нет ничего про саму разработку. Т.е. пришли некие люди, поменяли процесс. Как это повлияло на инженерные практики? Какие они были до? Какие они стали после? На каком основании одни заменились другими? Как это повлияло на технические метрики? Ничего этого нет. Есть только пара слов про убиение творческого начала. Потому что все это лишнее, мешающее, приземленное и плебейское, когда речь идет о высоком — поставке ценности, ценностях команды, самоорганизации и разделении принципов. Как это все может вообще работать при такой интерпретации? Да вообще никак. Оно, собственно, и не работает.
Чтобы сделать слои независимыми друг от друга, надо разорвать связь, т.е. убрать ссылку на класс B из класса A вообще :) Но это не в наших интересах, т.к. тогда приложение не сможет выполнять свои функции. В наших интересах эту связь ослабить, а делается это путем введения промежуточной абстракции (интерфейса или абстрактного класса). Понадобиться это может, если мы захотим, например, протестировать класс A изолированно от класса B (тогда мы заменим B фэйковой реализацией (моком) и подсунем его A). Или если мы предполагаем, что в дальнейшем мы можем использовать в системе другую реализацию B, но при этом не хотим, чтобы изменения вообще хоть как-то касались класса А. А вот как мы собираемся инстанцировать класс B — это уже вопрос отдельный, и именно при ответе на него и появляются фабрики, сервис локаторы и депенденси инжекшены.
Такова была идея автора этого принципа — Роберта Мартина. Если эту идею игнорировать, то вообще непонятно, что за инверсия там имеется в виду. В общем-то это чистая условность.
Совершенно верно, а еще зависимость от IBar/IServer так и остается для клиента класса Foo неявной.
«Вообще у него другая задача — когда заказчик хочет непонятный космический корабль, а на деле ему нужна глубоководная субмарина, но он этого не понимает, т.к. у него нет необходимых знаний, но есть какое-то смутное конечное видение из разряда: „Хочу большой корабль, способный бороздить бескрайние, чёрные глубины.“ Вот тут-то и приходит на помощь скрам, где всё делается постепенно и шаг за шагом. Т.е. в скраме развернутья и побежать в другое направление проще, нежели в последовательных методологиях.»
Ответом на это является инкрементность и итеративность. Клиент приходит, рассказывает сказки, через равные интервалы видит результат, вносит коррективы и так по кругу. Внимание, вопрос: где тут Скрам? Скрам как фрэймворк, безусловно, поддерживает итеративность и инкрементность через механизм спринтов. Но суть в том, что самих по себе их достаточно для обеспечения того, что вы описываете, и Скрам тут — ни к селу, ни к городу. Другое дело, если бы вы говорили, что инкрементности и итеративности может быть недостаточно для обеспечения надлежащего качества/объема работ или попадания в сроки при заданном бюджете. Вот тогда можно было бы говорить о Скраме как об инструменте, с помощью которого можно понять, где есть проблемы (на стороне PO, на стороне команды или и там, и там), которые снижают оные показатели. Еще раз — лакмус.