SOLID принципы: ISP (Принцип Разделения Интерфейса (The Interface Segregation Principle)
Вставка
- Опубліковано 25 лип 2024
- ISP Принцип разделения интерфейса (The Interface Segregation Principle) много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения
Курсы для новичков:
JAVA - bit.ly/3kDVgyN
JAVA Start - bit.ly/3kIrg4Q
Инструментарий JAVA - bit.ly/31OjxcK
Automation QA (Java) - bit.ly/2DXjF1p
ANDROID - bit.ly/2CtiDd4
C#/.NET - bit.ly/3gVHKnM
C# START - bit.ly/31NXMtE
PYTHON - bit.ly/30Rscfg
FRONT-END - bit.ly/3fZcLWp
WORDPRESS Developer - bit.ly/2Cq9HoF
SALESFORCE Developer - bit.ly/2Fg3VXK
UI/UX дизайн - bit.ly/2CoaCpC
Project management - bit.ly/3gVptqJ
Обучение на проекте - bit.ly/31T93Jf
Продвинутые курсы для состоявшихся девелоперов:
GRASP and GoF Design patterns - bit.ly/2DWD9mG
Enterprise patterns - bit.ly/3fWlZ5O
Сайт Foxminded: bit.ly/2CpCKc5
Foxminded в ФБ: / foxmindedco
FoxmindEd в Instagram: / foxminded.ua
Foxminded в VK: foxminded
Мой Telegram: t.me/nemchinskiyOnBusiness
Мой блог: www.nemchinsky.me
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) Зависимость на Абстракциях. Нет зависимости на что-то конкретное
1. в формулировке Роберта Мартина декларирует, что клиенты не должны зависеть от методов, которые они не используют. То есть если какой-то метод интерфейса не используется клиентом, то изменения этого метода не должны приводить к необходимости внесения изменений в клиентский код.
2. Следование принципу ISP заключается в создании интерфейсов, которые достаточно специфичны и требуют только необходимый минимум реализаций методов
3. Избыточные интерфейсы, напротив, могут требовать от реализующего класса создание большого количества методов, причём даже таких, которые не имеют смысла в контексте класса.
4. перекликается с принципом единственной ответственности
5. снижает сложность поддержки и развития приложения
6. Чем проще и минималистичнее используемый интерфейс, тем менее ресурсоёмкой является его реализация в новых классах, тем меньше причин его модифицировать
0:00 - вступление Сергея Немчинского
0:36 - все принципы SOLID в короткой формулировке
2:47 - формулировка принципа разделения интерфейса (The Interface Segregation Principle / ISP)
3:17 - Принцип разделения интерфейса на примерах
9:01 - почему хорошо следовать принципу ISP
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 ua-cam.com/video/NnM1Od1TKdA/v-deo.html
Побил фронтендеров. Они спросили за что. Я сказал что Немчинский разрешил. Они спросили кто это. Ещё раз побил.
как они посмели не знать кто это)
С удовольствием посмотрел все Ваши видео. Большое спасибо! Очень информативно и в то же время только по сути.
Обожаю твои видео. Каждое объяснение - не чтение с листочка, а пропитано колоссальным объёмом опыта.
Очень хочется услышать от тебя больше объяснений других абстрактных тем, типо того же рефакторинга, архитектуры приложений, а так же "DRY, KISS, YAGNI" как уже упоминалось :)
Спасибо тебе!
Сергей, спасибо, ждем другие принципы!
Спасибо. Наконец то я хоть как то начал понимать структуры ООП, а не лепить их по принципу "Работает"
радует :)
А как же главный принцип "И так сойдет"?))))
Спасибо) У нас недавно дали интернет, а тут уже почти все принципы разобрали)
Спасибо! Наконец-то нашел хорошее объяснение SOLID.
Спасибо. Очень интересно послушать про TDD и про то как писать юнит тесты. В смысле что тестировать, на что тестировать.
Сергей, мне реально нравится, как вы объясняете самые разные самые сложные темы просто и доступно. Уверен, что и любую из тех, что просят в комментариях вы классно расскажете. А вот увижу ли я когда-нибудь у Вас в руках маркеры или фломастеры, которые рисуют на бумаге хорошо видимые линии и буквы, я не уверен. Хотя я в общем-то оптимист. И верю в чудеса. Особенно в то, что вы сумеете сотворить чудо изображений на бумаге. Ну, всем нам удачи и спасибо за видео!
Я за теплоту и ламповость. Красиво анимированные ролики, где закадровый голос рассказывает как и что, и при этом появляются на экране какие-то схемы - круто, но не так чтобы впечатывается в память.
что, ждем, когда Сергей начнет объяснять тонкости квантовой физики простыми словами?)))
Очень важный принцип, идет рука об руку с первым, лайк!
на самом деле все принципы СОЛИДа тесно переплетаются между собой
Большое спасибо за выпуск!!!
Очень интересно, говори про всё)
Конечно интересно и про другие принципы!
Следующими надо делать DRY, KISS, YAGNI и рефакторинг
а планах
Следующим надо писать нормальный код, а не писать архитектуры ради архитектур.
Andrew Valkin это они ещё до VIPER и кодогенерации не дошли, где на один экран с одной кнопкой создаётся 48 классов и 93 протокола )
@@AlexanderPerechnev Лол, надеюсь, что я когда-нибудь прикоснусь к этим сокровенные знаниям по архитектуре приложения
@@AlexanderPerechnev Он сам попросится когда, сложность проекта возрастет. На мелких понятно, что Viper использовать избыточно.
Ставлю каждый принцип на повтор и смотрю пока не пойму и запомню. Помогает.
пока самый сильный видос из цикла. спасибо!
Да, итересно узнать про другие принципы
"Немчинский разрешил" - понял, буду юзать, спасибо )
Спасибо за крутой поучительный контент!
Большое спасибо за видео)
Про другие принципы ОЧЕНЬ ИНТЕРЕСНО!!!
Да и воообще про другие слова типа KISS и т д
Все очень круто, но хотелось бы увидеть объяснение ( конкретно этого принципа) на примере с кодом.
10:30 - Скинул своим фронтендерам. Сказали, что теперь боятся получить по голове и больше на работу не придут.
значит, они - не фронтендеры, а вротэнберы )))000
@@TheYuvelir Или он им дает задание и говорит что должно быть сделано вчера.
Мне если фронтендер скажет дать хоть что-нибудь, я ему дам пару примитивных методов типа findById и save и буду ждать что он с ними сможет сделать
Наверное, потому что и этого обычно не дают.)
я бы не сильно боялся, т.к. скинул это человек который не знает разницу между "ться" и "тся"
я вас очень уважаю! классный учитель
Очень интересно про другие принципы.
чьёрт побьери. никогда не доводилось слышать такую формулировку ISP. а ведь она чертовски верная!
Про остальные принципы тоже интересно
Сергей вы мне очень по душе , но каратин сделайте скидки на курсы я сразу пойду, вы прекрасный учитель
Все круто, кроме одного - надо срочно заправить все маркеры!
Спасибо большое 👍👍👍👍👍👍👍👍👍
Классная футболка :D
Спасибо.
Круто было бы еще про ACID.
Упс. Уже нашел на вашем канале) Спасибо
Спасибо спасибо спасибо 🙏🙏🙏
Про легкость реализации Mock-объектов интересно подмечено
Наконец-то грамотное объяснение ISP. Объяснение, в котором под клиентом подразумевается именно клиент (клиентский код), а не сервис, реализующий интерфейс. 99% статей/видео в качестве каноничного нарушения приводят ситуацию, когда сервис, реализующий большой интерфейс, вынужден бросать исключения в одном или нескольких методах, определенных в интерфейсе, потому что эти методы для него не релевантны. Но это, скорее, побочное явление, возникающее при нарушении ISP. Клиенты в таких статьях, как правило, вообще не рассматриваются. А начинать надо именно с них, потому что, как, опять же, сказано тут, именно клиенты определяют абстракции.
Лайк не глядя. Видео - в плейлист "to study". Спасибо за полезный контент и хорошую подачу!
Круто. Оооочень жду видео про возвращение NULL. Почему не надо так делать и как делать чтобы было правильно.
главное, чтобы Немчинский не вернул null вместо видео)))))
отлично
Интересно про другие принципы
про все расскажу
Про то, что заказчик/фронтендер должен описать что он хочет увидеть это в точку.
Расскажите про другие принципы, пожалуйста!
Сергей, расскажите про перспективы языка программирования Kotlin в бэкенд разработке.
Здравствуйте, Сергей!
С большым интересом смотрю ваши видео. Понятны становятся вещи, которые вы объясняете.
Только вот мне плохо видно на доске. Маркеры еле пишут или оранжевый фон перебивает зелёные цвета... Может сменить цвет на бордовый?
Сергей, а можно видео на тему: хватает ли у программистов времени на какое-то хобби, не связанное с программированием, могут ли программисты реализовываться потихоньку в какой-то другой области параллельно с работой
Нет, разве что по выходным 😉
❤️
Интересны все принципы Роберта Мартина!
👍
Agile и его связь Scrum было б интересно послушать)
Был фасад налоговой системы, а они там вдруг поумнели и сделали нормальную систему.
Звучит на грани фантастики )
Вопрос: IF должен наследоватся от IP? Или как?
Vi super, vse video kotorie ya smotriu, srazu ponemaiu!!
Боба Мартен... Давай ещё другие принципы Джорджа Мартина, будет крайне полезно нам всемь!
хорошая тема, я подумаю
Там два принципа: все сношаются, все умирают.
В назві відео не закрив дужку ")"!
Чому воно працює!?
Дякую за крутий контент!!!
Каким нужно быть человеком, чтобы за такой розжев солида диз влепить.
конченным =(
Человеком ли...?!
Не знаю, у меня никаких дизлайков нет, 2.7 к лайков, вот это уровень!
Сергей, сними пожалуйста видео про null, и почему его нельзя возвращать. Это сложная штука, которая с трудом поддается моему пониманию даже после десятка прочитанных статей на эту тему
PS. И самое главное, что делать вместо этого. Как писать код без null
Я читал, что вместо null нужно подставлять дефольтные классы-затычки, которые являются наследниками основного класса. Но лично у меня не всегда это получается.
@@user-zg8xo2yo4b У меня так же. Потому что это не будет работать, если у тебя весь код в процедурном стиле (даже если ты думаешь, что пишешь на ооп). Чтобы это взлетело, нужно пересмотреть весь подход к проектированию. И вот уже на эту тему интересно было бы глянуть видос
на c# я делаю функцию bool TryGetValue(out value) и горя не знаю. Если вернула false - значит, не удалось и в value по-любому null. По первым трем буквам сразу видно, что должно быть возвращено и не пропущена ли проверка условия
Потому что автор не в курсе, что помимо Java/C++ существуют ещё, например, Swift и Haskell с такой магией как optional, реализованной на enum.
OK!
В примере про зеленые интерфейсы для юзера и админке. Как-то между собой стоит их соотносить? в виде наследования например?
да по-любому придется, не дублировать же код
SOLID уже обсосали все кому не лень, а вот знать хоть на пол шишечки больше чем SOLID пригодится на собеседовании да и в работе. Надо говорить об этих принципах просто обязательно! Очень ждём!
love
Пересматривал, возник чисто технический вопрос. Если у фасада в первом примере 10 методов, то потенциальное число комбинаций необходимых в методах его клиентов - огромное. Завтра может понадобиться написать класс, которому нужны 1, 3 и 10 метод, послезавтра поставят задачу, для который нужно написать класс с 1, 7 и 8 методом. И мы для каждого плодим интерфейсы? И мы меняем постоянно строчку implements? А как же Open/Close принцип тогда? Мы, фактически, хотя и меняем только строчку implements, мы меняем класс Facade под каждую такую задачу
Интересно, я тоже так подумал, это как под каждый клиент, сервер должен интерфейс сочинять, под его хотелки? По мне, интерфейсы должен сочинять, кто то выше стоящий, а разработчики и сервера и разработчики клиентов должны ему удовлетворять.
Если так, то ведь просто создать 10 интерфейсов, и потом генерировать и совмещать как душе угодно. В этом и заключается данный принцип, изначально выстроить архитектуру проекта так, чтобы потом мы только работали на расширение. Тут просто видео совсем печальное
Насколько показывает практика, следующий же change request от клиента нарушит весь этот хипстерский дизайн. По мере усложнения клиентам нужно будет все больше методов, и в конечном итоге все это сольётся в один большой интерфейс.
"нужно больше методов!!!")))
Что в Unity является клиентским кодом?
6:29 когда нечаянно задеплоил в мастер ))
Здравствуйте, помогите понять. Частичный интерфейс как-то должен быть связан с полным интерфейсом? может быть нужно создать частичный интерфейс(IP) потом отнаследоваться от него полному(IF)? не уверена что интерфейсы могут наследоваться...
в Java могут :) А как это конкретно делать - возможны все перечисленные варианты. Какой правильный? зависит от вашего проекта
Сергей, не понятно, если ваш класс DF реашизует полный интерфейс IF где есть метод a() и клиентский интерфейс IP где тоже метод a() есть, то тогда возникает конфликт, если DF два эти интерфейса попробует заюзать. (ваш пример на 8й минуте)
Видимо, наследование нужно применить. Или разносить по двум разным интерфейсам и реализовывать их в одном классе на сервере
Описание элементов SOLID звучит так как будто бы это можно автоматом детектить в IDE, есть ли на эту тему разработки/наработки?
Это невозможно затетектить, логические косяки проектирования ни одна иде тебе не укажет
Я с утра вспомнила название первых трех, поняла, что четвертый и пятый не помню. Захожу в видео, а тут с листочка читают
Сергей, может FoxMinded пора выпускать учебную литературу?)
А вот если один класс использует 1 и 3 методы фасада, а второй класс использует 1 и 2 методы фасада. Дублировать эти методы в разных клиентских интерфейсах? Вроде как можно, потому что функциональность одна и метод в обоих интерфейсах будет в фасаде реализован. В случае если потребуется изменить контракт в одном из интерфейсах, то этот дублирующийся метод из этого интерфейса убирается, добавляется новый и он реализовывается в фасаде. Вроде норм. Но в самом фасаде создаются непонятки и не всегда ясно, что этот данный метод реализовывает два разных интерфейса.
:)
А как реализовать это на практике? Как от фасада взять нужные методы для интерфейсов? Забыть о фасаде и продублировать (копипастить) его методы в реализациях интерфейсов? И как вообще интерфейсы связаны с фасадом?
Фасад в данном примере сам реализует интерфейс, ничего копипастить ненадо. Просто в описании класса (в данном случае - фасада) добавляется использование интерфейса/ов.
Никак, забудь. Вся эта чушь пригодится только чтобы ответить на вопросы "синьоров" на собеседовании, больше пока что оно нигде не применимо.
Что имеется виду под словом "клиент"?
Я может в русском что не понимаю, но я знаю как минмум три значения этого слова и олно из них в програмировании можно интерпрерировать по разному.
Все ясно і доступно. Але я не зрозумів як реалізувати це на чистому JS без typescript. В JS немає інтерфейсів. Хіба може можна створювати якийсь адаптер з потрібними методами. Але чи не буде це ускладненням коду?
Все просто. Чистый JS - не ООП язык. То есть он слишком леворезьбовый, чтобы на нем можно было серьезно в архитектуру
Интересно а стакан из под кофе на майке случайно бело-красно-белый?)
8:07 почему не сделать ISelectable IInsertsble IUpdateable IDeleteable, и делать реализацию клиента путем множественной реализации интерфейсов?
на каждый метод по интерфейсу?! Это жестко...
@@maxlich9139 ну я же не зря сослался на время, речь у автора идет о частичной функциональности, предоставляемой клиенту. Разделить это по интерфейсам по сегментам ограничения, и имплементировать нужные интерфейсы в реализациях служб/клиентов будет более правильно..
@@maxlich9139 хотя..
Разве класс фасада это уже не нарушение srp?
Чёрт, как ты узнал, что я пытался начать смотреть с 4 видео?
Вот опять! Все было хорошо, пока речь не зашла о Фронт-Енде.
.
1) Есть взаимносовместимых подхода: API-First и Backend For Frontend. Так вот вопросы к фронтендерам типа "Дайте интерфейсы" -- это только для реализации BFF. Иначе "боль будет больная" для Всех. Рано или опоздно окажется, что фронт не может добавить новую функциональность потому, что бэк не поддерживает. А бэк не поддерживает потому, что фронт не заявил в требованиях. Ну давайте модель данных проектировать только по требованиям от Фронта. А чтобы зафейлиться поярче, давайте начнем с Mobile-First )
.
2) В принципе, спрашивать именно разработчиков о том, какие интерфейсы должны быть между фронтом и бэком (кстати, упомянутый в п. 1) BFF -- считается частью фронта), не есть хорошая затея. Дело в том, что это задача в некотором смысле обратна к задаче разработки, т.к. вместо того, чтобы получить спеку на вход, разработчик должен дать эту спеку на выходе (здесь главное не перепутать с документированием АПИ). Такое упражнение требует, и адекватной подготовки, и знания стратегии развития системы. Иными словами разработка интерфейсов между компонентами системы -- это задача архитектора (или человека, на которого возложены функции архитектора) или даже архитектурного коммитета.
.
3) и п.1) и п.2) ни в коем мере не нарушает правило: "Интерфейс принадлежит Клиенту". Просто у API потребителем может быть не только Фронтенд, а даже если только Фронтенд, то он может быть не единственным. В общем, чтобы начать идти "за интерфейсами" надо разобраться, кто есть Клиент этого АПИ. А до этого ... не надо "давать по голове" Фронтендерам, даже не смотря на то, что Немчинский разрешил.
Теперь вопрос: почему в языке программирования не сделать механизм, чтобы в интерфейсе прописывать класс, который он представляет, а не в классе прописывать миллион implements? Или это где-то уже есть?
Если фронтенденры не хотят четко запросить интерфейс дайте им GraphQL
а я думал дать по голове лучше)))
Можно увидить single method interface
Разделяют настолько, что один и только один метод остается...причем называют его одинаково, чтобы реализации разные были.
Позволяет решить проблему с перекомпиляцией всего приложения (если я правильно понял из видео как ведет себя джава), но в php это позволяет решить проблему создания не используемых объектов...
Ведь если один метод, то все что пришло в конструктор ьудет использовано 100% и так по цепочке зависимостей.
И упрощает тестирование...мокать один метод легко...если зависимостей более 13 то код воняет, нужно декомпозировать.
Откуда вы такие беретесь?
@@AlexanderPerechnev Вопрос с подвохом, не так ли?...
@@grommaks вопрос риторический, не требующий ответа.
Здравствуйте спасибо вам за все, что вы делаете. Хочу помочь вам, поэтому выскажу свое мнение (обычного пользователя) по поводу сайта foxminded, мне кажется он слишком нагруженным и плохо читаемым, т.е. если бы у меня не было точной цели обучаться и уважения к вам, я бы скорее всего не нажал на регистрацию и вообще закрыл сайт через минуты две. Возможно мое мнение предвзято, но оно основано на пользовательском опыте, я не разбираюсь в движках сайтов, но такой дизайн как у вас я видел очень большое количество раз, он не удобен пользователю, благо большинство ресурсов, постепенно, как мне кажется ещё в прошлом году начали уходить от этого, осмелюсь предположить, что ваш сайт на wordpress. У меня как у современного пользователя у которого явно выражена "рекламная слепота", сайты подобные вордпрессовским вызывают подобное чувство и даже некую злость. Так что рекомендую поменять дизайн сайта ну или хотя бы уменьшить количество текста, и протестировать на удобность на реальных пользователях - не знаю такая практика применяется или нет ...
Получается если у меня в классе 48 методов, я должен создать 48 интерфейсов с разными методами? Не бред ли?
А что значит замокана ? Метод замокан или бд замокана ?
вроде как мок на интерфейс
А что нам там будет делать внутри - это уже зависит от требований (но обычно ни в какие базы не лезет)
байт на коменты защитан.Давай про SCRUM лучше и про управление людьми.
можно ASID?
А что насчёт того, что фасаду придётся наследовать овер9000 интерфейсов, некоторые из которых ещё и имеют одинаковые методы! Это ужас.
Не, имхо но я такой пример не стал бы использовать. Фасад должен быть независим и быть на самой верхушке абстракций, а иначе у него будет ужасная здоровая сигнатура. Или же создать интерфейс для фасада из всех этих мелких интерфейсов, что конечно поможет, но плодить миллион таких фасадов не очень приятное занятие
зато не нарушается принцип ISP ) получается что не домен определяет общий интерфейс, а каждый клиент определяет интерфейс по потребности. меня самого коробит от такого подхода
Читать википедию на камеру с телефона это ж охренеть как позновательно.
Хотя бы купи второй вайтборд или распечатай крупной гарнитурой и развесь за камерой
Сделай лучше! Будем тебя смотреть, а не Немчинского.
Определение мы и без Сергея в вики найдем, а вот обьяснить, так что люди поняли, это уметь нужно, для этого и смотрим.
@@alekseykouzmenko9096 К сожалению, в IT кто умеет, тот работает. А кто не умеет тот учит других.
@@user-rg9ev4cm5z пхаха, окей, иди работай)0
@@user-rg9ev4cm5z Прискорбно
Сергей, блог Дяди Боба переехал на blog.cleancoder.com
по моему ISP какой то подозрительно простой, не правда ли?
а они все простые. Просто здравый смысл
Пошел к беку. Сказал, что я определяю интерфейс. Побили
Интерфейсы должен определять и давать архитектор, а не клиент или сервер.
Слышал такую фразу... "Принцип в принципе не принцип"
Зачем на собесах спрашивают SOLID если в компании они не используются?
Надеются найти того, кто начнет использовать)
Уже не "...всё ещё"?)
Собираем лайки на другие принципы
Почему вы до сих пор на мак не перешли, вроде как все крутые прогеры на продукциях яблоки сидят ?)
маркерную доску так и не купили😁...
она маркерная, просто все принципы мы писали в один день :)
пример 8:37 не валидный... ибо Общий и Частичный(или я не правильно понимаю ВАШЕ частичный) интерфейс ты не пронаследуешь, вы просто не понимаете принципа, либо ошиблись(хотя по мне Вы просто заговорились).. в том и прикол, что интерфейсы должны быть атомарными и не пересекаться.. к примеру в одном интерфейсе вся логика создания удаления, другой интерфейс поиск.. но не в коем случае ОБЪЕДИНЕНИЕ с ПОГЛОЩЕНИЕМ.. вы же сами нарушаете принцип и не замечаете, а уже ваш фасад пронаследуйте от этих 2 интерфейсов получив всю логику... на практике у вас клиент должен видеть классы в которых по необходимости реализованы комбинации из этих интерфейсов... разные классы с разным набором из атомарных интерфейсов, главное не переборщить и не довести что 1 метод = 1 интерфейс:)))) а то есть любители...
Просто все эти абстрактные интерфейсы/протоколы были придуманы для решения вполне конкретных задач. "Синьоры" снова увидели в этом "универсальный ключ к решению всех проблем" и пытаются натянуть сову на глобус. Уже сам факт того, что сервис на этапе создания решает кто и как к нему будет обращаться - нарушает все остальные принципы этого же самого SOLID.
Я изучаю пайтон и ничего не понял ( слишком джавовское объяснение
Просто в более половины современных языков нет такого понятия как протокол.