Java: SOLID принципы: OCP (Открытости/закрытости (Open Closed Principle) - видео HD
00:12:10
12n.ru 16775 роликов
21493 просмотра на сайте 12n.ru
SOLID принципы: OCP (Открытости/закрытости (Open Closed Principle) - видео.
При́нцип откры́тости/закры́тости (англ. The Open Closed Principle, OCP) — принцип ООП, устанавливающий следующее положение: «программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения»; Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification (Bertrand Meyer) — открыты для расширения: означает, что поведение сущности может быть расширено путём создания новых типов сущностей. — закрыты для изменения: в результате расширения поведения сущности, не должны вноситься изменения в код, который эту сущность использует. — Ценность принципа: нет необходимости в регрессионном тестированииТермин «принцип открытости/закрытости» имеет два значения: 1. Принцип открытости/закрытости Мейера 2. Полиморфный принцип открытости/закрытостиБертран Мейер в основном известен как основоположник термина Принцип открытости/закрытости, который появился в 1988 году в его книге Object-Oriented Software Construction, отвечая на вопрос: 1. Как можно разработать проект, устойчивый к изменениям, срок жизни которых превышает срок существования первой версии проекта? 2. однажды разработанная реализация класса в дальнейшем требует только исправления ошибок, а новые или изменённые функции требуют создания нового класса 3. реализация интерфейса может быть унаследована и переиспользована, но интерфейс может и измениться в новой реализации Полиморфный принцип открытости/закрытости: 1. основывается на строгой реализации интерфейсов и на наследовании от абстрактных базовых классов или на полиморфизме. 2. Созданный изначально интерфейс должен быть закрыт для модификаций, а новые реализации как минимум соответствуют этому изначальному интерфейсу, но могут поддерживать и другие, более расширенные. Статья Роберта С. Мартина «The Open-Closed Principle» в 1996 была одной из плодотворных статей для популяризации такого подходаКрэйг Ларман отнёс термин Принцип открытости/закрытости к шаблону Алистэра Кокбёрна, названного Protected VariationsКурсы для новичков:JAVA — bit.ly/3i9DlOaJAVA Start — bit.ly/2DIfBBKИнструментарий JAVA — bit.ly/2XClPdzAutomation QA (Java) — bit.ly/31viHS9ANDROID — bit.ly/2XwHofCC#/.NET — bit.ly/3fDLSqWC# START — bit.ly/3gA0usFPYTHON — bit.ly/3fB2fV6FRONT-END — bit.ly/31rmq2PWORDPRESS Developer — bit.ly/2Dlx8AaSALESFORCE Developer — bit.ly/2EYPs2qUI/UX дизайн — bit.ly/3iiTyk2Project management — bit.ly/3a1WQW9Обучение на проекте — bit.ly/2CalHL2Продвинутые курсы для состоявшихся девелоперов: GRASP and GoF Design patterns — bit.ly/3khIGF3Enterprise patterns — bit.ly/30zLq95Сайт Foxminded: bit.ly/3kkOygQFoxminded в ФБ: www.facebook.com/foxmindedco FoxmindEd в Instagram: www.instagram.com/foxminded.ua/Foxminded в VK: vk.com/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) Зависимость на Абстракциях. Нет зависимости на что-то конкретное0:00 – вступление Сергея Немчинского0:23 – про принципы SOLID1:12 – формулировка Open-Closed Principle (OCP)2:50 – почему хорошо следовать принципу открытости-закрытости3:53 – как соблюдать OCP согласно Бертрану Мейеру6:20 — как соблюдать OCP согласно Роберту Мартину (полиморфный OCP)8:25 –про расширение классов через интерфейсы
развернуть свернуть
Ну и да, доску нужно ближе и маркеры темнее или вообще перейти на запись видео с экрана, с электронной доской.
В любом случае спасибо за видео! Очень полезно послушать многие вещи, то как их другие понимают.
.
Так, вот, этот принцип не совсем про Классы и Интерфейсы, наследование и реализацию, и уж тем более, не про «замочки» на классах. Это все, конечно правильно, но, это все частные способы вносить изменения в код, который, кстати, не обязательно соответствует OCP. И применение к нему описанных техник изменения сохранит это свойство кода.
.
OCP о том, что следуя SRP мы также должны учитывать, что отдельные подзадачи могут иметь разные решения и выделять соответствующие абстракции, защищая этим самым решение общей задачи от изменений, и делая такое решение открытым для расширения. Т.е. OCP — это про декомпозицию кода. Именно, следуя OCP мы должны выделить наши зависимости, т.е. проанализировать, какие подзадачи могут иметь альтернативные решения, оценить вероятность такого измнения, что в свою очередь позволит не плодить лишнии абстракции.
.
На простом примере: Мы делаем функцию сортировку и используем в алгоритме простую конструкцию: a < b, чтобы понять надо ли нам поменять элементы местами или нет. Мы находимся в рамках SRP (т.е. наш алгоритм имеет одного Актора, решает одну задачу). Но, если нам надо будет реализовать сортировку уже по возрастанию (убыванию), то нам надо будет менять алгоритм, чего собственно мы и хотим избежать.
.
Так вот OCP говорит нам о том, что наш алгоритм сортировки должен абстрагироваться от реализации отношения порядка (что помимо всего прочего позволит абстрагироваться еще и по типу данных элементов коллекции).
.
Видео из объяснения OCP вылилось в расказ про DIP, где зависимости нам уже даны. OCP — про выявление зависимостей и создание абстракций.
.
На 9:20 Сергей дает пример Клиентского класса и Серверного класса, и говорит о том, что это нарушает OCP потому, что мы не можем расширить их взаимодействие. И здесь очень опасная и хитрая ошибка, которая заключается в том, что нам не надо расширять это взаимодействие. Нам надо расширить функциональность, а не взаимодействие отдельных двух компонентов.
.
В заключении, перефразирую Кота Матроскина:
— чтобы инвертировать что-нибудь «ненужное», сначала надо абстрагироваться по этому «ненужному», а мы об этом в видео не говорим…