SOLID принципы: DIP (Принцип инверсии зависимостей (The Dependency Inversion Principle)

SOLID принципы: DIP (Принцип инверсии зависимостей (The Dependency Inversion Principle) Зависимость на Абстракциях. Нет зависимости на что-то конкретное

Курсы для новичков:

Продвинутые курсы для состоявшихся девелоперов:

1. На основе работы Роберта Мартина (дяди Боба). Акроним SOLID предложен Michael Feathers
2. SOLID (сокр. от англ. single responsibility, open-closed, Liskov substitution, interface segregation и dependency inversion)

1. SRP Принцип единственной ответственности (The Single Responsibility Principle) - Каждый класс должен иметь одну и только одну причину для изменений.
2. OCP Принцип открытости/закрытости (The Open Closed Principle) - программные сущности … должны быть открыты для расширения, но закрыты для модификации
3. LSP Принцип подстановки Барбары Лисков (The Liskov Substitution Principle) объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы
4. ISP Принцип разделения интерфейса (The Interface Segregation Principle) много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения
5. DIP Принцип инверсии зависимостей (The Dependency Inversion Principle) Зависимость на Абстракциях. Нет зависимости на что-то конкретное

0:00 – вступление Сергея Немчинского
0:24 – формулировка The Dependency Inversion Principle (DIP)
0:55 – все принципы SOLID и место принципа инверсии зависимостей среди них
2:35 - как следовать принципу DIP
8:10 - про soft code, hard code и DIP

[asdclip]

Здравствуйте, Сергей. По поводу DIP, небольшое уточнение, если у вас высокоуровневый модуль A зависит от низкоуровнего модуля B и вы вынесете в модуле B интерфейс и теперь у вас A зависит от интерфейса модуля B, то это не будет DIP а скорее OCP. У вас как модуль A зависил от модуля B, так и зависит, только теперь от интерфейса. Смысл DIP - это инвертирования зависимостей без инвертирования потока управления. Поэтому интерфейс для B нужно объявлять в модуле A и получаем теперь, что А зависит только от своего интерфейса. а B уже зависит от А (зависимость инвертирована). Этот подход служит часто для изоляции одних слоев приложения от других, например доменного слоя от инфраструктуры.

[veryaev]

Спасибо за видео, все очень понятно!
Пока всего два вопроса!
1) Как вас зовут?
2) Большой ли у вас стаж в программировании?

[writetoyourdestiny]

Здравия, Сергей, хотелось бы услышать от вас про unit-тестирование, в частности про: Spy, Mock, Stab и еще вроде Fake.

[malferov]

Как рассказывать про инверсию зависимостей и не рассказать про инверсию зависимостей. Тот, кто знает, что такое DI, тот знает, что такое DI. А кто нет — нет. Вместо отлития в граните «все классы должны использоваться через интерфейсы», может быть, имело смысл показать пример, как инвертируются зависимости. На схеме, скажем.

[yurim]

О, холивар )
Это всё понятно, но есть некоторые вопросы, просто на подумать. Как раз связанные с тем, чем хреново ооп в принципе по сравнению с функциональщиной. Вот в этом видео прямо показывается, как один из недостатков ООП доводится до совершенства.
1. Так ли часто нужно вставлять новый функционал, который здесь привели в сравнении с тем, что надо всегда солому подстилать и все время делать больше? Например, там вы решили вставить функционал, может раз в полгода, а классов пишете кучу каждый день. И это а) просто заставляет вас делать больше усилий, б) постоянно больше усилий при дебаге или просто при переходах в среде разработки, в попытке выяснить какая реализация используется. А в то же время современные IDE вполне уже не просто текстовые редакторы, и довольно слабый аргумент, что надо лазить потом будет по всему коду, чтобы разорвать при случае зависимость и выставить интерфейс.
Т.е. это не утверждение, что данный подход плохо, просто сами попытайтесь оценить в своей работе, в своей среде разработки, в каком случае производительность программиста хуже.
2. Интерфейс уменьшает зависимость, да. Но ее не всегда надо с коробки уменьшать. Программа - это рельсы для поезда. Поезд должен ездить жестко по ним. В первую очередь программа должна быть жесткой, потому как у нее первая задача - работать правильно, выполняя заложенные требования. А уже 2я, или даже 22я, это антагоническая цель - быть гибкой, потому что что-то может измениться в требованиях. Интерфейс - это набор сигнатур методов. А сигнатура - пример сайдэффекта. Т.е. в ООП вообще нет гарантии что передавая один и те же аргументы, вы будете получать одни и те же результаты, потому что дзёбанные объекты имеют состояние (по сути, поля - это глобальные переменные, за которые ругали еще в процедурном подходе). А интерфейс добавляет хардкора в топку, это прям вот идеальный кот в мешке )) Вы еще и имеете возможность подменять реализацию, одна будет у вас в одном случае, другая в другом, и особенно в юнит тестах. Т.е. получается, что вы сознательно в юнит-тестах окружаете код некими конструкциями, которые ТОЧНО будут работать не так, как это работать будет вживую. По сути, что такое сайдэффект. Работа программы зависит, ну типа как от неких глобальных переменных, и черт знает, какие они будут, когда случится бага, и как себя поведет программа в тех или иных случаях. И вы, когда пишете тест, пытаетесь угадать, какие значения переменных в окружении будут в реале, или выставить так, что на ваш взгляд, оно покроет все разные варианты. Много тестов будет просто ради тестов, потому как в реале эти интерфейсы будут только подмножество вариантов своей работы выдавать. А можно и пропустить реальный кейс. (тут я не рассматриваю, что юнит-тесты должны каждую ветку тестить, но смысл, что у вас оверхед будет по тестам).

Это так, на подумать, это не критика ;) Не всё так однозначно. Хотя, если так случилось, что выбрали ООП, то вариантов как лучше, не так и много )

[ivanivanovq]

Наконец послушал про "d". Роберт Мартин в своих лекиях про солид обычно рассказывает только про "sol"

[starfall]

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

[yashkevich]

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

[bandirom]

Покажите каждый принцип на практике, на джаве или любо чем)

[dmitriygordievskiy]

Спасибо, посмотрев видео наконец-то понял SOLID. В других источниках с которыми сталкивался либо слишком абстрактно пояснено, либо заумно.

[yoetdyg]

поддерживаю. Тема тестирования очень актуальна. Хочется получить информацию в присущей для вас доступной манере подаче информации

[FoRGeish]

С возможностями современных(ной) IDE писать на каждый чих интерфейс - тоже такое себе занятие, противоречащее KISS'у. Как и с балансом между хард и софт, нужно соблюдать баланс между "все на интерфейсах"/"ни одного интерфейса в проекте". ИМХО

[feoktant]

Вот когда появится задача добавить авторизацию, в ИДЕ есть кнопка Extract Interface на классе, и делается дальше всё что вы рассказали.

[mjcdmok]

После размышлений на эту тему я возможно понял суть, но мое умозаключение отличается от того что вы написали выше - как я понял dep-inversion - это не БУКВАЛЬНЫЙ разворот зависимости в противоположную сторону, а её трансформация. Классы низкого уровня реализуют единый интерфейс, в свою очередь параметр(который и представляет зависимость) конструктора класса высокого уровня реализует тот же самый единый интерфейс. Таким образом, какой бы аргумент(зависимость) мы бы не кинули в конструктор, пока аргумент отвечает интерфейсу - класс будет работать. В итоге теперь класс высокого уровня ЗАВИСИТ не от класса низкого уровня, а от интерфейса в конструкторе. В свою очередь классы низкого уровня ТОЖЕ ЗАВИСЯТ от интерфейса. Это значит, что изменения в классе низкого уровня не соответствующие интерфейсу, который связывает его с классом высокого уровня, повлекут за собой изменения этого интерфейса, которые в свою очередь повлекут и изменения в коде класса высокого уровня(Ведь его параметр конструктора ТОЖЕ реализует этот интерфейс). Поэтому считаю конкретно это предложение из коммента выше неверным и вредным для новичков которые его читают: "если мы будем что-то менять в UserRepository, или мы можем изменить имя класса, а можем вообще унаследовать другой класс, то это никак не затронет UserClient, нам не нужно вносить изменения в его код". А в сам пример с UserClient и UserRepository я бы для того, чтобы показать именно суть добавил бы класс UserRepository2, который тоже реализует интерфейс IUserRepository, но по-другому(возможно с другой логикой) - и тогда класс UserClient мог бы работать и с UserRepository и с UserRepository2, и как раз при изменении зависимости, то есть самого передаваемого аргумента в конструкторе код в классе UserClient менять бы НЕ ПРИШЛОСЬ, так как для него UserRepository и UserRepository2 это по сути одно и тоже, но под капотом разное. Вот и получается, что теперь UserClient плевать с каким классом работать, вот только полной независимости от классов низкого уровня он все-таки не получил, по причине того, что при любом изменении в IUserRepository придется менять код в классе UserClient. Надеюсь верно и более-менее понятно написал. Если есть реально шарящие люди в этой теме, то надеюсь отпишут хоть что-то в ответ, так как я новичок и с этой темой поломал уже голову некоторое время чисто из-за того что все пишут, что если применить dep-inversion, то можно менять внутренности более низкоуровневых модулей не парясь об высокоуровневых, так вот я реально голову сломал пытаясь понять - как же они не будут влиять, если они от ОДНОГО ИНТЕРФЕЙСА ЗАВИСЯТ.

[evgenykuksov]

Бля, просто в душу поразила ваша манера объяснять! Так иногда не хватает грубых слов в общении/объяснении, потому что благодаря им в разы быстрее понимается!) Мое почтение за формат)

[MikhailKolesnikov]

увы, вызов всего через интерфейсы тоже бывает организован "через одно место".

например, когда интерфейс делается вида:
void doJob(JobParameters params, Object yet_another_parameter, Long timeout, String log_prefix, int node_id)

ну и так далее.... :)

[alexanderbelov]

10:06 Есть такая штука - рефакторинг кода.
Делай раз: Создай интерфейсы по принципу SOLID/ISP, которые реализует класс.
Делай два: Унаследуй жёсткий класс от всех интерфейсов, чтобы он их реализовывал.
Делай три: Измени клиентов, чтобы они использовали новые интерфейсы вместо жёсткого класса.
Танцы с бубном окончены.

[cuwhrmc]

Было бы интересно послушать о TDD. Спасибо за вашу работу

[simplechannel]

Еще даже не посмотрел видео, а уже поставил лайк. Надо завязывать с такой привычкой

[sergijg]

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