SOLID в объектно-ориентированном программировании

SOLID — это набор принципов (рекомендаций) которые призваны помочь в создании качественного объектно-ориентированного кода приложения. Они позволяют создавать чистый код (как написанный, так и спроектированный), который будет в дальнейшем, и тестировать, и поддерживать. Давайте подробно познакомимся с каждым из принципов.

Что такое SOLID?

На самом деле SOLID является красивой аббревиатурой из букв пяти основных принципов, входящих в это понятие. Данное определение было предложено Робертом Мартином. В переводе с английского слово solid означает твердый, прочный, надежный, цельный. Такими же свойствами обладают и программы написанные с использованием этих принципов. Но это не волшебная палочка, которая может гарантировать вам написание выдающегося продукта. Однако, следование принципам SOLID значительно повышает вероятность этого. Ведь основной целью этих принципов является создание расширяемой и легко поддерживаемой системы.

Признаки плохого кода

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

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

The Single Responsibility Principle (SRP) — Принцип единственной ответственности

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

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

The Open Closed Principle (OCP) — Принцип открытости/закрытости

Сущности должны быть открыты для расширения, но закрыты для модификации.

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

The Liskov Substitution Principle (LSP) — Принцип подстановки Лисков

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

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

The Interface Segregation Principle (ISP) — Принцип разделения интерфейса

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

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

The Dependency Inversion Principle (DIP) — Принцип инверсии зависимости

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Под этой достаточно большой формулировкой имеется ввиду следующее (разберем каждое предложение по очереди):

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

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

Заключение

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