SOLID: Принцип единственной ответственности

Понимание принципов разработки программного обеспечения – это то, что отличает хороших разработчиков от великих. Любой программист может написать код, но не каждый напишет отличный код. Как принцип единой ответственности (Single Responsibility Principle) может помочь вам написать отличный код?

Изучение программирования начинается с основ разработки iOS: переменных, функций, синтаксиса Swift, структур данных, алгоритмов и SDK iOS. Как только вы изучите основы и создадите несколько проектов приложений, пришло время повысить свой уровень и освоить принципы проектирования программного обеспечения SOLID.

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

Как разработчик, вы можете выбирать из множества принципов разработки программного обеспечения и архитектурных шаблонов: SOLID, DRY, GRASP, KISS – не говоря уже о таких подходах, как MVC, MVP, MVVM, FRP и VIPER.

SOLID – это мнемоническое выражение, обозначающая:

S – The Single Responsibility Principle – Принцип единственной ответственности
О – The Open Closed Principle – Принцип открытости/закрытости
L – The Liskov Substitution Principle – Принцип подстановки Барбары Лисков
I – The Interface Segregation Principle – Принцип разделения интерфейса
D – The Dependency Inversion Principle – Принцип инверсии зависимостей

Принцип единой ответственности: делать только одно

Первым принципом SOLID является принцип единой ответственности (SRP). Вы можете грубо перевести его как «Делай только одно».

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

Это означает две вещи:

Класс должен делать только одно.
Может быть только одна причина, чтобы изменить определенный класс.

Когда класс несет единственную ответственность, он делает одну вещь, и поэтому имеет только одну причину для изменения: когда «вещь», которую он делает, изменяется! Отсюда и название «принцип единой ответственности» .

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

Посмотрим на практический пример.

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

Вы можете создать класс ReportGenerator в своем приложении. Он берет данные для отчета, форматирует их и экспортирует отчет в файл PDF.

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

Внезапно вы вспоминаете принцип единственной ответственности и понимаете свою ошибку. Вместо одной ответственности у вашего класса есть три:

Сбор данных для отчета.
Создать форматирование отчета.
Экспорт отчета.

Единая ответственность определяется как «одна причина для изменения», а не «одна ответственность». Вы можете утверждать, что «генерация отчетов» – это одна из обязанностей, и вы были бы правы. Тогда зачем вам разбивать данный класс на несколько классов?

Существенным отличием является «причина для изменений». У каждого из этих трех классов теперь есть одна причина для изменения: изменить сбор данных, изменить формат отчета и экспортировать его. Три класса легче поддерживать и отлаживать, чем 1 класс с 3 причинами для изменения.

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

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

Принцип единой ответственности действителен не только для классов. Подумай об этом:

Приложение должно решить одну проблему и только одну проблему. Нашли новую проблему? Создайте новое приложение.
Библиотека кода должна выполнять одну задачу. Нужна еще одна задача? Напишите новую библиотеку.
Компонент должен заключать в себе одну ответственность. Нужен компонент, чтобы сделать больше? Напишите код для нового компонента.