solid
TRANSCRIPT
![Page 2: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/2.jpg)
Принципы SOLID
Классы — это блоки, из которых строится приложение Java.
![Page 3: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/3.jpg)
Принципы SOLID
Если материал, из которого построено здание —
некачественный, рано или поздно для такое здание может
развалится.
![Page 4: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/4.jpg)
Принципы SOLID
Некачественно написанные классы однажды могут привести к трудной ситуации в процессе
работы приложения.
![Page 5: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/5.jpg)
Принципы SOLID
Хорошо разработанные и качественно написанные
классы могут ускорить процесс разработки и уменьшить
количество ошибок.
![Page 6: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/6.jpg)
Принципы SOLID
Хорошо разработанные и качественно написанные классы и интерфейсы не
нуждаются в изменениях, при изменении требований к
программе.
![Page 7: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/7.jpg)
Принципы SOLID
SOLID — обозначает пять основных принципов
построения системы на основе ООП.
![Page 8: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/8.jpg)
Принципы SOLID
Принципы SOLID применяются вместе и предназначены для
повышения вероятности того, что программист создаст систему,
которую будет легко поддерживать и расширять в течение долгого
времени.
![Page 9: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/9.jpg)
SOLID Принцип единственной обязанности
Single responsibility principle(S) - на каждый объект должна быть возложена одна единственная обязанность.
![Page 10: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/10.jpg)
SOLID Принцип единственной обязанности
Каждый объект должен иметь только одну обязанность и эта
обязанность должна быть полностью инкапсулирована в
класс.
![Page 11: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/11.jpg)
SOLID Принцип единственной обязанности
Все открытые интерфейсы класса должны быть
направлены исключительно на обеспечение этой обязанности.
![Page 12: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/12.jpg)
SOLID Принцип единственной обязанности
Например, представьте себе модуль, который составляет и печатает отчёт. Такой модуль может измениться по двум причинам. Во-первых, может измениться само содержимое отчёта. Во-вторых, может измениться формат отчёта. Оба этих фактора изменяют модуль по разным причинам: в одном случае изменение содержательное, а во втором — косметическое.
![Page 13: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/13.jpg)
SOLID Принцип единственной обязанности
Принцип единственной обязанности говорит, что оба аспекта этой проблемы на самом деле являются двумя разными обязанностями, и в таком случае должны находиться в разных классах или модулях. Объединение двух сущностей, изменяющихся по разным причинам и в разное время, считается плохим проектным решением.
![Page 14: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/14.jpg)
SOLID Принцип открытости/закрытости
Open/closed principle(O) - говорит о том, что программные сущности
должны быть открыты для расширения, но закрыты для
изменений. Объекты в программе могут быть заменены их наследниками без изменения свойств программы.
![Page 15: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/15.jpg)
SOLID Принцип открытости/закрытости
Открыты для расширения.Это означает, что поведение модуля
можно расширить. Когда требования к приложению изменяются, мы
добавляем в модуль новое поведение, отвечающее изменившимся
требованиям. Иными словами, мы можем изменить состав функций
модуля.
![Page 16: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/16.jpg)
SOLID Принцип открытости/закрытости
Закрыты для модификации. Расширение поведения модуля не
сопряжено с изменениями в исходном или двоичном коде
модуля. Двоичное исполняемое
представление модуля, остается неизменным.
![Page 17: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/17.jpg)
SOLID Принцип подстановки Барбары Лисков
Liskov substitution principle(L) - принцип подстановки Барбары Лисков, который говорит, что
функция, использующая базовый тип, должна иметь возможность использовать подтипы базового
типа, не зная об этом.
![Page 18: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/18.jpg)
SOLID Принцип подстановки Барбары Лисков
Производные классы не должны усиливать предусловия (не должны требовать большего от своих клиентов).
Производные классы не должны ослаблять постусловия (должны гарантировать, как минимум тоже, что и супер класс).
![Page 19: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/19.jpg)
Принцип подстановки Барбары Лисков
Принцип подстановки Лисков не является панацеей в вопросах
наследования, он лишь помогает формализовать, в каких пределах может варьироваться поведение
наследника с точки зрения контракта базового класса.
![Page 20: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/20.jpg)
Принцип подстановки Барбары Лисков
В своих трудах Барбара Лисков строила свой анализ на основе
контрактов класса: •предусловий •постусловий •инвариантов.
.
![Page 21: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/21.jpg)
Принцип подстановки Барбары Лисков
С помощью контрактов мы можем хотя бы с некоторой долей
уверенности утверждать, что поведение наследника и базового класса является согласованным.
![Page 22: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/22.jpg)
SOLID Принцип подстановки Барбары Лисков
Производные классы не должны нарушать инварианты базового класса (инварианты базового класса и наследников суммируются)
Производные классы не должны генерировать исключения, не описанные базовым классом.
![Page 23: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/23.jpg)
SOLID Принцип разделения интерфейса
Interface segregation princilpe(I) - говорит о том, что лучше иметь множество
специализированных интерфейсов, чем один универсальный.
Клиенты не должны быть вынуждены реализовывать ненужные методы, которые они не будут использовать
![Page 24: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/24.jpg)
SOLID Принцип инверсии зависимостей
Dependency inversion principle(D) – принцип инверсии зависимости
говорит о том, что зависимости в системе должны строиться на
основе абстракций.
![Page 25: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/25.jpg)
Принцип инверсии зависимостей
Модули нижнего уровня не должны зависеть от модулей верхнего
уровня. И те и те должны зависеть от абстракций.
В свою очередь, абстракции не должны зависеть от деталей. Детали должны зависеть от
абстракций.
![Page 26: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/26.jpg)
SOLID Принцип инверсии зависимостей
Вместо создания зависимостей напрямую, класс должен требовать их у более высокого уровня через аргументы
метода или конструктора. При этом зависимость должна
передаваться не в виде экземпляров конкретных классов, а в виде
интерфейсов или абстрактных классов.
![Page 27: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/27.jpg)
SOLID Принцип инверсии зависимостей
Суть принципа инверсии зависимостей проста: Заменить композицию на
агрегацию.
![Page 28: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/28.jpg)
SOLID Принцип инверсии зависимостей
DI выражается простым правилом:«Зависеть надо от абстракций».
Не должно быть зависимостей от конкретных классов;
Все связи в программе должны вести на абстрактный класс или интерфейс.
![Page 29: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/29.jpg)
SOLID Принцип инверсии зависимостей
Не должно быть переменных, в которых хранятся ссылки на конкретные классы.
Не должно быть классов, производных от конкретных классов.
Не должно быть методов, переопределяющих метод, реализованный в одном из базовых классов.
![Page 30: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/30.jpg)
SOLID коротко
![Page 31: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/31.jpg)
SOLID принципы
SOLID принципы сами по себе не дадут вам прекрасный OO-дизайн!
Существуют обоснованные причины и ситуации когда их лучше не
использовать или обойти, но это должно быть осознанное решение, а не прихоть
или незнание.
![Page 32: SOLID](https://reader035.vdocuments.site/reader035/viewer/2022070518/58e49d371a28abf5428b56a5/html5/thumbnails/32.jpg)
SOLID принципы
Необходимо всегда оценивать, что
приобретаем и что улучшаем с использованием
SOLID.