ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก
SOLID принципы: ISP (Принцип Разделения Интерфейса (The Interface Segregation Principle)
ฝัง
- เผยแพร่เมื่อ 14 ส.ค. 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/nemchinsk...
Мой блог: 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
📈 Открыт набор на новый поток авторского тренинга "GRASP и GoF Design Patterns", начало 02.09.2024. Регистрируйтесь сейчас со скидкой для ранних пташек🐦 -30% до 11.08!👉 - go.foxminded.ua/3WCF44x
Сергей, мне реально нравится, как вы объясняете самые разные самые сложные темы просто и доступно. Уверен, что и любую из тех, что просят в комментариях вы классно расскажете. А вот увижу ли я когда-нибудь у Вас в руках маркеры или фломастеры, которые рисуют на бумаге хорошо видимые линии и буквы, я не уверен. Хотя я в общем-то оптимист. И верю в чудеса. Особенно в то, что вы сумеете сотворить чудо изображений на бумаге. Ну, всем нам удачи и спасибо за видео!
Я за теплоту и ламповость. Красиво анимированные ролики, где закадровый голос рассказывает как и что, и при этом появляются на экране какие-то схемы - круто, но не так чтобы впечатывается в память.
что, ждем, когда Сергей начнет объяснять тонкости квантовой физики простыми словами?)))
Побил фронтендеров. Они спросили за что. Я сказал что Немчинский разрешил. Они спросили кто это. Ещё раз побил.
как они посмели не знать кто это)
Спасибо. Наконец то я хоть как то начал понимать структуры ООП, а не лепить их по принципу "Работает"
радует :)
А как же главный принцип "И так сойдет"?))))
Очень важный принцип, идет рука об руку с первым, лайк!
на самом деле все принципы СОЛИДа тесно переплетаются между собой
Обожаю твои видео. Каждое объяснение - не чтение с листочка, а пропитано колоссальным объёмом опыта.
Очень хочется услышать от тебя больше объяснений других абстрактных тем, типо того же рефакторинга, архитектуры приложений, а так же "DRY, KISS, YAGNI" как уже упоминалось :)
Спасибо тебе!
Спасибо! Наконец-то нашел хорошее объяснение SOLID.
Спасибо) У нас недавно дали интернет, а тут уже почти все принципы разобрали)
Следующими надо делать DRY, KISS, YAGNI и рефакторинг
а планах
Следующим надо писать нормальный код, а не писать архитектуры ради архитектур.
Andrew Valkin это они ещё до VIPER и кодогенерации не дошли, где на один экран с одной кнопкой создаётся 48 классов и 93 протокола )
@@AlexanderPerechnev Лол, надеюсь, что я когда-нибудь прикоснусь к этим сокровенные знаниям по архитектуре приложения
@@AlexanderPerechnev Он сам попросится когда, сложность проекта возрастет. На мелких понятно, что Viper использовать избыточно.
С удовольствием посмотрел все Ваши видео. Большое спасибо! Очень информативно и в то же время только по сути.
10:30 - Скинул своим фронтендерам. Сказали, что теперь боятся получить по голове и больше на работу не придут.
значит, они - не фронтендеры, а вротэнберы )))000
@@TheYuvelir Или он им дает задание и говорит что должно быть сделано вчера.
Мне если фронтендер скажет дать хоть что-нибудь, я ему дам пару примитивных методов типа findById и save и буду ждать что он с ними сможет сделать
Наверное, потому что и этого обычно не дают.)
я бы не сильно боялся, т.к. скинул это человек который не знает разницу между "ться" и "тся"
Сергей, спасибо, ждем другие принципы!
Спасибо. Очень интересно послушать про TDD и про то как писать юнит тесты. В смысле что тестировать, на что тестировать.
"Немчинский разрешил" - понял, буду юзать, спасибо )
Спасибо за крутой поучительный контент!
Все очень круто, но хотелось бы увидеть объяснение ( конкретно этого принципа) на примере с кодом.
Очень интересно, говори про всё)
👨💻 После Senior ВСЕ? Как программисту развиваться после Senior и куда двигаться в айти? 👉 th-cam.com/video/NnM1Od1TKdA/w-d-xo.html
Да, итересно узнать про другие принципы
Про другие принципы ОЧЕНЬ ИНТЕРЕСНО!!!
Да и воообще про другие слова типа KISS и т д
Сергей вы мне очень по душе , но каратин сделайте скидки на курсы я сразу пойду, вы прекрасный учитель
Ставлю каждый принцип на повтор и смотрю пока не пойму и запомню. Помогает.
Все круто, кроме одного - надо срочно заправить все маркеры!
чьёрт побьери. никогда не доводилось слышать такую формулировку ISP. а ведь она чертовски верная!
Большое спасибо за видео)
я вас очень уважаю! классный учитель
Про остальные принципы тоже интересно
Конечно интересно и про другие принципы!
Наконец-то грамотное объяснение ISP. Объяснение, в котором под клиентом подразумевается именно клиент (клиентский код), а не сервис, реализующий интерфейс. 99% статей/видео в качестве каноничного нарушения приводят ситуацию, когда сервис, реализующий большой интерфейс, вынужден бросать исключения в одном или нескольких методах, определенных в интерфейсе, потому что эти методы для него не релевантны. Но это, скорее, побочное явление, возникающее при нарушении ISP. Клиенты в таких статьях, как правило, вообще не рассматриваются. А начинать надо именно с них, потому что, как, опять же, сказано тут, именно клиенты определяют абстракции.
Классная футболка :D
пока самый сильный видос из цикла. спасибо!
Большое спасибо за выпуск!!!
Интересно про другие принципы
про все расскажу
Расскажите про другие принципы, пожалуйста!
Очень интересно про другие принципы.
Про легкость реализации Mock-объектов интересно подмечено
Спасибо.
Круто было бы еще про ACID.
Упс. Уже нашел на вашем канале) Спасибо
Круто. Оооочень жду видео про возвращение NULL. Почему не надо так делать и как делать чтобы было правильно.
главное, чтобы Немчинский не вернул null вместо видео)))))
Спасибо большое 👍👍👍👍👍👍👍👍👍
Лайк не глядя. Видео - в плейлист "to study". Спасибо за полезный контент и хорошую подачу!
Сергей, сними пожалуйста видео про null, и почему его нельзя возвращать. Это сложная штука, которая с трудом поддается моему пониманию даже после десятка прочитанных статей на эту тему
PS. И самое главное, что делать вместо этого. Как писать код без null
Я читал, что вместо null нужно подставлять дефольтные классы-затычки, которые являются наследниками основного класса. Но лично у меня не всегда это получается.
@@user-zg8xo2yo4b У меня так же. Потому что это не будет работать, если у тебя весь код в процедурном стиле (даже если ты думаешь, что пишешь на ооп). Чтобы это взлетело, нужно пересмотреть весь подход к проектированию. И вот уже на эту тему интересно было бы глянуть видос
на c# я делаю функцию bool TryGetValue(out value) и горя не знаю. Если вернула false - значит, не удалось и в value по-любому null. По первым трем буквам сразу видно, что должно быть возвращено и не пропущена ли проверка условия
Потому что автор не в курсе, что помимо Java/C++ существуют ещё, например, Swift и Haskell с такой магией как optional, реализованной на enum.
Пересматривал, возник чисто технический вопрос. Если у фасада в первом примере 10 методов, то потенциальное число комбинаций необходимых в методах его клиентов - огромное. Завтра может понадобиться написать класс, которому нужны 1, 3 и 10 метод, послезавтра поставят задачу, для который нужно написать класс с 1, 7 и 8 методом. И мы для каждого плодим интерфейсы? И мы меняем постоянно строчку implements? А как же Open/Close принцип тогда? Мы, фактически, хотя и меняем только строчку implements, мы меняем класс Facade под каждую такую задачу
Интересно, я тоже так подумал, это как под каждый клиент, сервер должен интерфейс сочинять, под его хотелки? По мне, интерфейсы должен сочинять, кто то выше стоящий, а разработчики и сервера и разработчики клиентов должны ему удовлетворять.
Если так, то ведь просто создать 10 интерфейсов, и потом генерировать и совмещать как душе угодно. В этом и заключается данный принцип, изначально выстроить архитектуру проекта так, чтобы потом мы только работали на расширение. Тут просто видео совсем печальное
Сергей, расскажите про перспективы языка программирования Kotlin в бэкенд разработке.
Каким нужно быть человеком, чтобы за такой розжев солида диз влепить.
конченным =(
Человеком ли...?!
Не знаю, у меня никаких дизлайков нет, 2.7 к лайков, вот это уровень!
В назві відео не закрив дужку ")"!
Чому воно працює!?
Дякую за крутий контент!!!
Вопрос: IF должен наследоватся от IP? Или как?
отлично
Насколько показывает практика, следующий же change request от клиента нарушит весь этот хипстерский дизайн. По мере усложнения клиентам нужно будет все больше методов, и в конечном итоге все это сольётся в один большой интерфейс.
"нужно больше методов!!!")))
Спасибо спасибо спасибо 🙏🙏🙏
Сергей, а можно видео на тему: хватает ли у программистов времени на какое-то хобби, не связанное с программированием, могут ли программисты реализовываться потихоньку в какой-то другой области параллельно с работой
Нет, разве что по выходным 😉
Был фасад налоговой системы, а они там вдруг поумнели и сделали нормальную систему.
Звучит на грани фантастики )
Про то, что заказчик/фронтендер должен описать что он хочет увидеть это в точку.
Здравствуйте, Сергей!
С большым интересом смотрю ваши видео. Понятны становятся вещи, которые вы объясняете.
Только вот мне плохо видно на доске. Маркеры еле пишут или оранжевый фон перебивает зелёные цвета... Может сменить цвет на бордовый?
Боба Мартен... Давай ещё другие принципы Джорджа Мартина, будет крайне полезно нам всемь!
хорошая тема, я подумаю
Там два принципа: все сношаются, все умирают.
Интересны все принципы Роберта Мартина!
Здравствуйте, помогите понять. Частичный интерфейс как-то должен быть связан с полным интерфейсом? может быть нужно создать частичный интерфейс(IP) потом отнаследоваться от него полному(IF)? не уверена что интерфейсы могут наследоваться...
в Java могут :) А как это конкретно делать - возможны все перечисленные варианты. Какой правильный? зависит от вашего проекта
SOLID уже обсосали все кому не лень, а вот знать хоть на пол шишечки больше чем SOLID пригодится на собеседовании да и в работе. Надо говорить об этих принципах просто обязательно! Очень ждём!
❤️
Agile и его связь Scrum было б интересно послушать)
Разве класс фасада это уже не нарушение srp?
Все ясно і доступно. Але я не зрозумів як реалізувати це на чистому JS без typescript. В JS немає інтерфейсів. Хіба може можна створювати якийсь адаптер з потрібними методами. Але чи не буде це ускладненням коду?
Все просто. Чистый JS - не ООП язык. То есть он слишком леворезьбовый, чтобы на нем можно было серьезно в архитектуру
В примере про зеленые интерфейсы для юзера и админке. Как-то между собой стоит их соотносить? в виде наследования например?
да по-любому придется, не дублировать же код
👍
Vi super, vse video kotorie ya smotriu, srazu ponemaiu!!
OK!
6:29 когда нечаянно задеплоил в мастер ))
Сергей, не понятно, если ваш класс DF реашизует полный интерфейс IF где есть метод a() и клиентский интерфейс IP где тоже метод a() есть, то тогда возникает конфликт, если DF два эти интерфейса попробует заюзать. (ваш пример на 8й минуте)
Видимо, наследование нужно применить. Или разносить по двум разным интерфейсам и реализовывать их в одном классе на сервере
Описание элементов SOLID звучит так как будто бы это можно автоматом детектить в IDE, есть ли на эту тему разработки/наработки?
Это невозможно затетектить, логические косяки проектирования ни одна иде тебе не укажет
Я с утра вспомнила название первых трех, поняла, что четвертый и пятый не помню. Захожу в видео, а тут с листочка читают
Что имеется виду под словом "клиент"?
Я может в русском что не понимаю, но я знаю как минмум три значения этого слова и олно из них в програмировании можно интерпрерировать по разному.
А вот если один класс использует 1 и 3 методы фасада, а второй класс использует 1 и 2 методы фасада. Дублировать эти методы в разных клиентских интерфейсах? Вроде как можно, потому что функциональность одна и метод в обоих интерфейсах будет в фасаде реализован. В случае если потребуется изменить контракт в одном из интерфейсах, то этот дублирующийся метод из этого интерфейса убирается, добавляется новый и он реализовывается в фасаде. Вроде норм. Но в самом фасаде создаются непонятки и не всегда ясно, что этот данный метод реализовывает два разных интерфейса.
Что в Unity является клиентским кодом?
8:07 почему не сделать ISelectable IInsertsble IUpdateable IDeleteable, и делать реализацию клиента путем множественной реализации интерфейсов?
на каждый метод по интерфейсу?! Это жестко...
@@maxlich9139 ну я же не зря сослался на время, речь у автора идет о частичной функциональности, предоставляемой клиенту. Разделить это по интерфейсам по сегментам ограничения, и имплементировать нужные интерфейсы в реализациях служб/клиентов будет более правильно..
@@maxlich9139 хотя..
Сергей, может FoxMinded пора выпускать учебную литературу?)
А как реализовать это на практике? Как от фасада взять нужные методы для интерфейсов? Забыть о фасаде и продублировать (копипастить) его методы в реализациях интерфейсов? И как вообще интерфейсы связаны с фасадом?
Фасад в данном примере сам реализует интерфейс, ничего копипастить ненадо. Просто в описании класса (в данном случае - фасада) добавляется использование интерфейса/ов.
Никак, забудь. Вся эта чушь пригодится только чтобы ответить на вопросы "синьоров" на собеседовании, больше пока что оно нигде не применимо.
Интересно а стакан из под кофе на майке случайно бело-красно-белый?)
love
Вот опять! Все было хорошо, пока речь не зашла о Фронт-Енде.
.
1) Есть взаимносовместимых подхода: API-First и Backend For Frontend. Так вот вопросы к фронтендерам типа "Дайте интерфейсы" -- это только для реализации BFF. Иначе "боль будет больная" для Всех. Рано или опоздно окажется, что фронт не может добавить новую функциональность потому, что бэк не поддерживает. А бэк не поддерживает потому, что фронт не заявил в требованиях. Ну давайте модель данных проектировать только по требованиям от Фронта. А чтобы зафейлиться поярче, давайте начнем с Mobile-First )
.
2) В принципе, спрашивать именно разработчиков о том, какие интерфейсы должны быть между фронтом и бэком (кстати, упомянутый в п. 1) BFF -- считается частью фронта), не есть хорошая затея. Дело в том, что это задача в некотором смысле обратна к задаче разработки, т.к. вместо того, чтобы получить спеку на вход, разработчик должен дать эту спеку на выходе (здесь главное не перепутать с документированием АПИ). Такое упражнение требует, и адекватной подготовки, и знания стратегии развития системы. Иными словами разработка интерфейсов между компонентами системы -- это задача архитектора (или человека, на которого возложены функции архитектора) или даже архитектурного коммитета.
.
3) и п.1) и п.2) ни в коем мере не нарушает правило: "Интерфейс принадлежит Клиенту". Просто у API потребителем может быть не только Фронтенд, а даже если только Фронтенд, то он может быть не единственным. В общем, чтобы начать идти "за интерфейсами" надо разобраться, кто есть Клиент этого АПИ. А до этого ... не надо "давать по голове" Фронтендерам, даже не смотря на то, что Немчинский разрешил.
Получается если у меня в классе 48 методов, я должен создать 48 интерфейсов с разными методами? Не бред ли?
А что насчёт того, что фасаду придётся наследовать овер9000 интерфейсов, некоторые из которых ещё и имеют одинаковые методы! Это ужас.
Не, имхо но я такой пример не стал бы использовать. Фасад должен быть независим и быть на самой верхушке абстракций, а иначе у него будет ужасная здоровая сигнатура. Или же создать интерфейс для фасада из всех этих мелких интерфейсов, что конечно поможет, но плодить миллион таких фасадов не очень приятное занятие
зато не нарушается принцип ISP ) получается что не домен определяет общий интерфейс, а каждый клиент определяет интерфейс по потребности. меня самого коробит от такого подхода
Если фронтенденры не хотят четко запросить интерфейс дайте им GraphQL
а я думал дать по голове лучше)))
Можно увидить single method interface
Разделяют настолько, что один и только один метод остается...причем называют его одинаково, чтобы реализации разные были.
Позволяет решить проблему с перекомпиляцией всего приложения (если я правильно понял из видео как ведет себя джава), но в php это позволяет решить проблему создания не используемых объектов...
Ведь если один метод, то все что пришло в конструктор ьудет использовано 100% и так по цепочке зависимостей.
И упрощает тестирование...мокать один метод легко...если зависимостей более 13 то код воняет, нужно декомпозировать.
Откуда вы такие беретесь?
@@AlexanderPerechnev Вопрос с подвохом, не так ли?...
@@grommaks вопрос риторический, не требующий ответа.
Чёрт, как ты узнал, что я пытался начать смотреть с 4 видео?
Читать википедию на камеру с телефона это ж охренеть как позновательно.
Хотя бы купи второй вайтборд или распечатай крупной гарнитурой и развесь за камерой
Сделай лучше! Будем тебя смотреть, а не Немчинского.
Определение мы и без Сергея в вики найдем, а вот обьяснить, так что люди поняли, это уметь нужно, для этого и смотрим.
@@alekseykouzmenko9096 К сожалению, в IT кто умеет, тот работает. А кто не умеет тот учит других.
@@user-rg9ev4cm5z пхаха, окей, иди работай)0
@@user-rg9ev4cm5z Прискорбно
Здравствуйте спасибо вам за все, что вы делаете. Хочу помочь вам, поэтому выскажу свое мнение (обычного пользователя) по поводу сайта foxminded, мне кажется он слишком нагруженным и плохо читаемым, т.е. если бы у меня не было точной цели обучаться и уважения к вам, я бы скорее всего не нажал на регистрацию и вообще закрыл сайт через минуты две. Возможно мое мнение предвзято, но оно основано на пользовательском опыте, я не разбираюсь в движках сайтов, но такой дизайн как у вас я видел очень большое количество раз, он не удобен пользователю, благо большинство ресурсов, постепенно, как мне кажется ещё в прошлом году начали уходить от этого, осмелюсь предположить, что ваш сайт на wordpress. У меня как у современного пользователя у которого явно выражена "рекламная слепота", сайты подобные вордпрессовским вызывают подобное чувство и даже некую злость. Так что рекомендую поменять дизайн сайта ну или хотя бы уменьшить количество текста, и протестировать на удобность на реальных пользователях - не знаю такая практика применяется или нет ...
можно ASID?
Теперь вопрос: почему в языке программирования не сделать механизм, чтобы в интерфейсе прописывать класс, который он представляет, а не в классе прописывать миллион implements? Или это где-то уже есть?
байт на коменты защитан.Давай про SCRUM лучше и про управление людьми.
А что значит замокана ? Метод замокан или бд замокана ?
вроде как мок на интерфейс
А что нам там будет делать внутри - это уже зависит от требований (но обычно ни в какие базы не лезет)
Пошел к беку. Сказал, что я определяю интерфейс. Побили
Интерфейсы должен определять и давать архитектор, а не клиент или сервер.
:)
Сергей, блог Дяди Боба переехал на blog.cleancoder.com
по моему ISP какой то подозрительно простой, не правда ли?
а они все простые. Просто здравый смысл
достаточно сложное объяснение. Проще так:
1) при несоблюдении нужно имлементить лишнии методы когда реализуеш интерфейс
2) большой интерфейс "позволяет" разработчику использовать много методов там, где этого делать не стоит и это добавляет лишние зависимости
3) при соблюдении проще понять как интерфейс буде использоваться внутри класа\метода
Зачем на собесах спрашивают SOLID если в компании они не используются?
Надеются найти того, кто начнет использовать)
Уже не "...всё ещё"?)
Почему вы до сих пор на мак не перешли, вроде как все крутые прогеры на продукциях яблоки сидят ?)
Налоговая поумнела? - зачем мистика в видео?
Собираем лайки на другие принципы
пример 8:37 не валидный... ибо Общий и Частичный(или я не правильно понимаю ВАШЕ частичный) интерфейс ты не пронаследуешь, вы просто не понимаете принципа, либо ошиблись(хотя по мне Вы просто заговорились).. в том и прикол, что интерфейсы должны быть атомарными и не пересекаться.. к примеру в одном интерфейсе вся логика создания удаления, другой интерфейс поиск.. но не в коем случае ОБЪЕДИНЕНИЕ с ПОГЛОЩЕНИЕМ.. вы же сами нарушаете принцип и не замечаете, а уже ваш фасад пронаследуйте от этих 2 интерфейсов получив всю логику... на практике у вас клиент должен видеть классы в которых по необходимости реализованы комбинации из этих интерфейсов... разные классы с разным набором из атомарных интерфейсов, главное не переборщить и не довести что 1 метод = 1 интерфейс:)))) а то есть любители...
Просто все эти абстрактные интерфейсы/протоколы были придуманы для решения вполне конкретных задач. "Синьоры" снова увидели в этом "универсальный ключ к решению всех проблем" и пытаются натянуть сову на глобус. Уже сам факт того, что сервис на этапе создания решает кто и как к нему будет обращаться - нарушает все остальные принципы этого же самого SOLID.