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

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

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

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

а можно видео потом про DI & IoC?

Спасибо! Очень крутой цикл роликов. обязательно скину друзьям.

Спасибо большое за видео!

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

Большое спасибо за ваши видеоролики

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

Спасибо, весь курс хорош)

за СОЛИД и двор, лайк в упор

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

Доходчиво и достаточно коротко!

Вовремя открыл ютуб (5 сек назад залито). Спасибо за видео.

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

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

Сергей, все правильно, так и пишем, несогласных стараемся убедить :)

хорошие лекции, спасибо за ваш труд.

Thank you SO MUCH!!!

Расскажите пожалуйста про самые интересные, на ваш взгляд, принципы, которые описывал Роберт Мартин по мимо принципов SOLID

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

Спасибо за видео!

Спасибо! Все понятно.

ПРОСТО ТОП!! СПАСИБО!!

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

спасибо за видео, поддержите видео комментариями!

C наступающем Новым Годом, Сергей. В целом с вами согласен, с единственной оговоркой. Использовать класс через интерфейс нужно при внешнем взаимодействии к этому классу, если понимаете о чем я. Если класс реализует обертку настроек или DTO то не вижу смысла этого делать.

Зростання вашому каналу! Хорошу справу робите!

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

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

Вы очень крут!!!

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

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

Здравствуйте, можете потом снять видео про дизайн паттерны(behavioral, structural), хотя-бы по 2-3 паттерна с каждого. Ещё что такое downcasting и почему его использование это плохо.

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

Не хватает наглядной демонстрации через блок схемы. Делали на предыдущих принципах, а тут почему-то не стали :(

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

Миллион лайков этому видео! Как открыл для себя удобство прогр-я через интерфейсы, до сих пор кипятком ссусь от счастья) Хотелось бы подобный ролик еще и про DI/IoC.

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

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

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

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

Говорит что надо все делать ч/з интерфейс, тогда что же является софткод?

@Sergey Nemchinskiy Там SRP в назві

3:25 такие задачи как логирование и профайлинг зачастую делаются через аспекты. На первый взгляд это смотрится довольно лаконично, без кучи самодельных интерфейсов и декораторов; вся магия остаётся под капотом АОП-фреймворков. Сергей, сделайте как-нибудь видео про АОП, пожалуйста, мб есть какие-то подводные камни.

Добрый день, очень хотелось бы увидеть все принципы SOLID в виде кода, хорошо бы java.

Хотелось бы про TDD

залпом посмотрел

Огромное спасибо за видео но не хватает примера для полного понимания

Найкраще пояснення SOLID що я чув, набагато краще ніж Шевчук!

во, какраз думал "когда же будет видео про D"))

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

Может быть, я не очень умный, но я посмотрел весь плейлист и по-прежнему не понимаю, почему в описанном случае нельзя просто добавить к классу Server метод authorization() или т.п.? Нужна авторизация - дописываем авторизацию, ну в чём проблема-то?

Спасибо, ничего непонятно

Наверное самый часто нарушаемый принцип)

Приведите, пожалуйста , примеры DIP, было без DIP так, с DIP стало так...

годно

А разве интерфейс или декоратор не нарушают принцип единственной ответственности?

GRASP

Ничерта не понимаю, как добавления новых методов в класс сервера аффектит мой класс клиента. Допустим у меня есть объект класса Сервер в классе Клиент. Через него я вызываю необходимые мне методы. Как добавление новых методов в класс Сервер может сломать работу класса Клиент??? Ну добавились новые методы и что? Хочу вызову, хочу нет... Объясните плиз, я вообще не отдупляю плюсы работы с классами через интерфейс!

Ну не особо надо все вызывать через интерфейс. Если надо выделить интерфейс можно за 5 секунд. Зачем его делать заранее? Хотя вот если у нас библиотека, то ее Api лучше через интерфейсы развязать.

Сергей, плиз, го антипаттерны.

OK!

На 04:55 он говорит "добавить шаблон прокси из гов". Что за гов? Благодарю за ответ.

а примеров бы

Ребят, возник вопрос, который прям не дает покоя: - Не противоречит ли принципе DIP паттерну Creator. По DIP надо объекты передавать другим объектам через их интерфейсы, а по Creator'у эти объекты следует создавать там, где они используются. Как разрешить это противоречие?

Я только не понял почему в видео про принцип открытости закрытости та же самая инф

что такое юнит тест ?

Даеш видео о паттернах

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

про GRASP бы и закон Деметры послушать

Ну вот не факт. Бывают функциональные единицы с несколькими зависимостями, которые используются приватно только в данном контексте и не имеют смысла вне его, но которые все же инъектируются через DI. Писать каждый раз по этому поводу новый интерфейс -- это по большей части моральная мастурбация. Тут больше применимы принципы yagni и kiss.

8:05 Берете и расширяете функциональность в нужном....шта?

Компьютерная инженерия-это IT ? Если пойти в университет на такой факультет,можно ли потом пойти работать программистом ?

что значит вызывать класс через интерфейс?)

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

не знаю оговрка это была или нет но -SRP принцип единственной ответственности. Каждый класс должен иметь только одну зону ответственности.

Не на каждый класс интерфейс, а на каждый класс, содержащий сложное поведение - интерфейс. Ну не делать же интерфейсы для dto и подобных

Где же инверсия? Что инвертируют-то? И при чём тут интерфейсы? :)

Название поправьте!

Теперь у меня есть принципы, знаете-ли, и я себя не на помойке нашел

Не ну прям на каждый класс - это хрень. На важные классы - да, надо.

Можно пожалуйста книги для новичков про java на русском.

DRY KISS

Единственный минус DI - все превращается в магию, и потом хрен разберешься что откуда берется, и что как с чем связано

Что там по мок и стаб Кратенько )

Крч все видео в одном предложение: юзайте классы через интерфейсы.

Что значит замокать ?)))

Ага, когда пишешь на Яве, когда производительность - это ниже твоего достоинства, когда это не говно-код, а ты так видишь... тогда таки да - всё виртуальное и везде интерфейсы. Осталось только, чтоб авторы STL одумались и всё переписали на интерфейсах.

Декомпозиция предметной области

DRY тоже надо :)

GoF patterns, растолкуй, плиз

в названии - DIP, в превью - SRP

испорчу картину лайков, поставлю 334-ый :D

И ЭТО ПО ПРЕЖНЕМУ СЕРГЕЙ НЕМЧИНСКИЙ, ИУУУУУУУУУ 😊

Mock vs stub

Вот здесь крутое объяснение этого принципа: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-Uq10IqZhf7U.htmlsi=yITNxUdvpP1f4fhb

Базовые определения не для понимания, а для галочки такое ощущение!

Дуже цікавить просто і доступно про AOP. Для чого воно, які задачі вирішує, основні принципи.

+++++