🐍 SOLID

Сегодня я решил затронуть тему пяти принципов объектно-ориентированного программирования и проектирования.

Вот они слева направо:

Принцип единственной ответственности (Single Responsibility Principle, SRP) - каждый класс должен иметь только одну ответственность
Принцип открытости/закрытости (Open/Closed Principle, OCP) - классы должны быть открыты для расширения, но закрыты для модификации
Принцип подстановки Барбары Лисков (Liskov Substitution Principle, LSP) - объекты должны быть заменяемыми на своих наследников без изменения корректности программы
Принцип разделения интерфейса (Interface Segregation Principle, ISP) - клиенты не должны зависеть от методов, которые они не используют
Принцип инверсии зависимостей (Dependency Inversion Principle, DIP) - высокоуровневые модули не должны зависеть от низкоуровневых модулей. Оба типа модулей должны зависеть от абстракций

А теперь поговорим о каждом в отдельности

S. Принцип единственной ответственности

Single Responsibility Principle, далее по тексту SRP.

Согласно принципу SRP, класс должен иметь только одну ответственность. Это означает, что класс должен быть спроектирован таким образом, чтобы он решал только одну задачу или выполнял только одну функцию. Другими словами, каждый класс должен быть отвечать только за один аспект функциональности приложения.

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

Нарушение принципа SRP обычно приводит к «раздутому» коду, который трудно понять, поддерживать и тестировать. Его также может быть трудно расширять в будущем, которое может привести к дополнительным ошибкам и сбоям в системе.

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

Open/Closed Principle aka OCP гласит, что программные сущности (классы, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения.

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

Принцип OCP позволяет сделать систему более гибкой и легко расширяемой, позволяя разработчикам добавлять новую функциональность, не беспокоясь о том, что это повлияет на уже существующий код. В результате будет улучшена устойчивость к изменениям (resistance to change) системы.

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

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

Liskov Substitution Principle или же LSP - говорит, что объекты в программе могут быть заменены своими наследниками без изменения корректности самой программы.

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

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

Пример использования принципа LSP: допустим, что есть базовый класс «Животное», у которого есть метод «Питаться». Если создается подкласс «Кошка», то она должна также иметь метод «Питаться», который будет работать аналогично базовому классу. Если метод «Питаться» в подклассе «Кошка» будет работать иначе, то это нарушит принцип LSP.

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

Interface Segregation Principle он же ISP гласит о том, что клиенты не должны зависеть от методов, которые они не используют.

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

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

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

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

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

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

Заключение

Эти принципы помогают создавать гибкие, расширяемые и легко поддерживаемые системы. И тебя точно спросят о них на собеседовании (это я гарантирую).