ООП и SOLID

1.

ООП и SOLID
astondevs.ru

2.

Основные принципы ООП
1.
Инкапсуляция
2.
Наследование
3.
Полиморфизм
4.
Абстракция

3.

Инкапсуляция
Инкапсуляция - механизм языка, позволяющий соединить данные
и методы, работающие с этими данными в один объект и скрыть
детали реализации от пользователя.
Инкапсуляция позволяет нам пользоваться возможностями класса
без создания угрозы безопасности данных за счет ограничения
прямого доступа к его полям. Также она позволяет изменять код
классов не создавая проблем их пользователям (другим классам).
В Java данный принцип достигается за счет использования
ключевого слова private.

4.

Наследование
Наследование — это включение поведения (т.е. методов) и состояния (т.е.
переменных) базового класса в производный класс, таким образом они
становятся доступны в этом производном классе.
Преимущества:
- Повторное использование кода
- Модуляризация
- Устанавливается логическое отношение «is a» (является кем-то, чем-то).
Например: Dog is an animal. (Собака является животным).
Недостаток:
- Сильная связанность: подкласс зависит от реализации родительского класса,
что делает код сильно связанным.

5.

Полиморфизм
Полиморфизм предоставляет возможность единообразно обрабатывать объекты с различной
реализацией при условии наличия у них общего интерфейса или класса. По-простому:
способность вызывать нужные методы у объектов, имеющие разные типы (но находящиеся
в одной иерархии). При этом происходит автоматический выбор нужного метода в зависимости
от типа объекта.

6.

Абстракция
Основная цель использования данной концепции — это уменьшение сложности компонентов программы
за счет скрытия от потребителей, ненужных ему подробностей. Это позволяет реализовать более сложную
логику поверх предоставленной абстракции, не вдаваясь в подробности ее реализации.
Приготовление кофе с помощью кофемашины является хорошим примером абстракции. Все, что нам надо
знать, что бы ей пользоваться: как налить воды, засыпать кофейные зерна, включить и выбрать вид кофе,
который хотим получить. А, как машина будет варить кофе — нам знать не нужно.

7.

SOLID

8.

S - Single responsibility
Принцип единственной ответственности — принцип ООП, обозначающий, что
каждый модуль должен иметь одну ответственность и эта ответственность должна быть
полностью инкапсулирована в класс. Все его поведения должны быть направлены
исключительно на обеспечение этой ответственности.
Под ответственностью понимается причина, по которой этот модуль может быть изменен.
Например, представьте себе класс, который составляет и печатает отчёт. Такой класс может
измениться по двум причинам:
1) может измениться само содержимое отчёта
2) может измениться формат отчёта.
Логично, что оба аспекта этих причин на самом деле являются двумя разными
ответственностями.

9.

O - open-closed
— принцип открытости/закрытости
Программные сущности должны быть открыты для расширения и закрыты для изменения.
Когда вы меняете текущее поведение класса, эти изменения сказываются на всех системах,
работающих с данным классом. Если хотите, чтобы класс выполнял больше операций, то
идеальный вариант – не заменять старые на новые, а добавлять новые к уже существующим.
Принцип служит для того, чтобы делать поведение класса более разнообразным, не
вмешиваясь в текущие операции, которые он выполняет. Благодаря этому вы избегаете ошибок
в тех фрагментах кода, где задействован этот класс.

10.

L - liskov substitution
— принцип подстановки Барбары Лисков
Имеет сложное математическое определение, которое можно заменить на: Функции, которые
используют базовый тип, должны иметь возможность использовать подтипы базового типа, не
зная об этом.
Это видно на простом примере создания объекта Collection.
List <String> strings = new ArrayList<>();
1) Также очень важно! Реализация в классах наследниках не должна противоречить
реализации в базовых классах. В том числе нельзя закрывать методы в дочерних классах.
2) Нельзя вызывать методы не характерные для базовой реализации

11.

I - interface segregation
— принцип разделения интерфейсов
Под интерфейсом здесь понимается именно Java интерфейс. Разделение интерфейса
облегчает использование и тестирование модулей.
Программные сущности не должны зависеть от методов, которые они не используют.
Принцип разделения интерфейсов говорит о том, что слишком «толстые» интерфейсы
необходимо разделять на более маленькие и специфические, чтобы программные сущности
маленьких интерфейсов знали только о методах, которые необходимы им в работе.

12.

D - dependency inversion
Принцип инверсии зависимостей. Объектом зависимости должна быть абстракция, а не что-то
конкретное.
● Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа
модулей должны зависеть от абстракций.
● Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Что такое модули верхних уровней? Как определить этот уровень? Как оказалось, все очень
просто. Чем ближе модуль к вводу/выводу, тем ниже уровень модуля. Т.е. модули, работающие
с BD, интерфейсом пользователя, являются низкоуровневыми. А модули, реализующие бизнеслогику являются высокоуровневыми.

13.

Литература
• https://habr.com/ru/post/508086/
• https://www.youtube.com/watch?v=O4uhPCEDzSo
• https://www.youtube.com/watch?v=x5OtQiKOG-Q&t=314s
• https://www.youtube.com/watch?v=otrfSgeK3JI