SOLID

SOLID

Виталий Унгурян [email protected]

Принципы SOLID

Классы — это блоки, из которых строится приложение Java.


Если материал, из которого построено здание —

некачественный, рано или поздно для такое здание может

развалится.


Некачественно написанные классы однажды могут привести к трудной ситуации в процессе

работы приложения.


Хорошо разработанные и качественно написанные

классы могут ускорить процесс разработки и уменьшить

количество ошибок.


Хорошо разработанные и качественно написанные классы и интерфейсы не

нуждаются в изменениях, при изменении требований к

программе.


SOLID — обозначает пять основных принципов

построения системы на основе ООП.


Принципы SOLID применяются вместе и предназначены для

повышения вероятности того, что программист создаст систему,

которую будет легко поддерживать и расширять в течение долгого

времени.

SOLID Принцип единственной обязанности

Single responsibility principle(S) - на каждый объект должна быть возложена одна единственная обязанность.


Каждый объект должен иметь только одну обязанность и эта

обязанность должна быть полностью инкапсулирована в

класс.


Все открытые интерфейсы класса должны быть

направлены исключительно на обеспечение этой обязанности.


Например, представьте себе модуль, который составляет и печатает отчёт. Такой модуль может измениться по двум причинам. Во-первых, может измениться само содержимое отчёта. Во-вторых, может измениться формат отчёта. Оба этих фактора изменяют модуль по разным причинам: в одном случае изменение содержательное, а во втором — косметическое.


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

SOLID Принцип открытости/закрытости

Open/closed principle(O) - говорит о том, что программные сущности

должны быть открыты для расширения, но закрыты для

изменений. Объекты в программе могут быть заменены их наследниками без изменения свойств программы.


Открыты для расширения.Это означает, что поведение модуля

можно расширить. Когда требования к приложению изменяются, мы

добавляем в модуль новое поведение, отвечающее изменившимся

требованиям. Иными словами, мы можем изменить состав функций

модуля.


Закрыты для модификации. Расширение поведения модуля не

сопряжено с изменениями в исходном или двоичном коде

модуля. Двоичное исполняемое

представление модуля, остается неизменным.

SOLID Принцип подстановки Барбары Лисков

Liskov substitution principle(L) - принцип подстановки Барбары Лисков, который говорит, что

функция, использующая базовый тип, должна иметь возможность использовать подтипы базового

типа, не зная об этом.


Производные классы не должны усиливать предусловия (не должны требовать большего от своих клиентов).

Производные классы не должны ослаблять постусловия (должны гарантировать, как минимум тоже, что и супер класс).

Принцип подстановки Барбары Лисков

Принцип подстановки Лисков не является панацеей в вопросах

наследования, он лишь помогает формализовать, в каких пределах может варьироваться поведение

наследника с точки зрения контракта базового класса.


В своих трудах Барбара Лисков строила свой анализ на основе

контрактов класса: •предусловий •постусловий •инвариантов.

.


С помощью контрактов мы можем хотя бы с некоторой долей

уверенности утверждать, что поведение наследника и базового класса является согласованным.


Производные классы не должны нарушать инварианты базового класса (инварианты базового класса и наследников суммируются)

Производные классы не должны генерировать исключения, не описанные базовым классом.

SOLID Принцип разделения интерфейса

Interface segregation princilpe(I) - говорит о том, что лучше иметь множество

специализированных интерфейсов, чем один универсальный.

Клиенты не должны быть вынуждены реализовывать ненужные методы, которые они не будут использовать

SOLID Принцип инверсии зависимостей

Dependency inversion principle(D) – принцип инверсии зависимости

говорит о том, что зависимости в системе должны строиться на

основе абстракций.

Принцип инверсии зависимостей

Модули нижнего уровня не должны зависеть от модулей верхнего

уровня. И те и те должны зависеть от абстракций.

В свою очередь, абстракции не должны зависеть от деталей. Детали должны зависеть от

абстракций.


Вместо создания зависимостей напрямую, класс должен требовать их у более высокого уровня через аргументы

метода или конструктора. При этом зависимость должна

передаваться не в виде экземпляров конкретных классов, а в виде

интерфейсов или абстрактных классов.


Суть принципа инверсии зависимостей проста: Заменить композицию на

агрегацию.


DI выражается простым правилом:«Зависеть надо от абстракций».

Не должно быть зависимостей от конкретных классов;

Все связи в программе должны вести на абстрактный класс или интерфейс.


Не должно быть переменных, в которых хранятся ссылки на конкретные классы.

Не должно быть классов, производных от конкретных классов.

Не должно быть методов, переопределяющих метод, реализованный в одном из базовых классов.

SOLID коротко

SOLID принципы

SOLID принципы сами по себе не дадут вам прекрасный OO-дизайн!

Существуют обоснованные причины и ситуации когда их лучше не

использовать или обойти, но это должно быть осознанное решение, а не прихоть

или незнание.

SOLID принципы

Необходимо всегда оценивать, что

приобретаем и что улучшаем с использованием

SOLID.

Education

SOLID