Следующая статья поможет вам: SOLID: принцип единой ответственности
Вернуться в блог
Понимание принципов проектирования программного обеспечения — вот что отличает хороших разработчиков от великих. Любой может писать код, но не каждый программист пишет отличный код. Может ли принцип единой ответственности помочь вам написать отличный код?
Улучшение навыков программирования начинается с основ разработки для iOS: переменных, функций, синтаксиса Swift, структур данных, алгоритмов и iOS SDK. После того, как вы изучили эти основы и создали несколько проектов приложений, пришло время повысить уровень и освоить принципы проектирования программного обеспечения SOLID.
Точно так же, как вы можете разрабатывать графику, пользовательский интерфейс или пользовательский интерфейс, вы также можете разрабатывать программное обеспечение. Код — это просто краска на холсте, а дизайн — это продуманность, с которой был написан этот код. Цель хорошей архитектуры приложения — сделать код более простым для чтения, обслуживания, повторного использования, отладки и расширения.
Как разработчик, вы можете выбирать из множества принципов проектирования программного обеспечения и архитектурных шаблонов: SOLID, DRY, GRASP, KISS, не говоря уже о таких подходах, как MVC, MVP, MVVM, FRP и VIPER.
Понимание SOLID всегда превосходит любой другой подход, потому что SOLID лежит в основе каждого из других подходов к проектированию программного обеспечения. (В дополнение к DRY и KISS. Подробнее об этом позже.)
SOLID — это мнемоника, означающая:
- Принцип единой ответственности
- Принцип открыт-закрыт
- Принцип замены Лискова
- Принцип разделения интерфейсов
- Принцип инверсии зависимостей
Давайте перейдем к первому: принципу единой ответственности. Вот так!
Первым принципом SOLID является принцип единой ответственности (SRP). Примерно это можно перевести как «Делай только одну вещь».
В программировании на Swift вы используете классы для создания своих приложений. Класс — это базовый строительный блок вашего приложения, компонент, имеющий одну цель. Принцип единой ответственности гласит, что у класса должна быть только одна причина для изменения.
На самом деле это означает две вещи:
Класс должен делать только одну вещь
Есть только одна причина сменить определенный класс
Когда класс несет единственную ответственность, он делает одну вещь и, следовательно, имеет только одну причину для изменений: когда «вещь», которую он делает, меняется! Отсюда и произошло название «принцип единой ответственности».
Вы нарушаете принцип единой ответственности, когда у класса несколько обязанностей. Это станет яснее всего, когда вы обнаружите, что существует более одной причины сменить класс.
Вы не знакомы с архитектурой приложений и почему это важно? Начните с этого руководства: Почему важна архитектура приложения.
Давайте рассмотрим практический пример.
Вы создаете приложение, которое генерирует отчеты. Каждый день приложение генерирует отчет о таких вещах, как школьные оценки, показатели производительности, входящие электронные письма или твиты, которые вы отправили. Twitter.
Вы можете создать класс ReportGenerator в своем приложении. Он берет данные для отчета, форматирует их и экспортирует отчет в файл PDF.
Некоторое время спустя вы решаете, что хотите изменить внешний вид отчета. Ему нужен новый шрифт, несколько других цветов и дополнительная таблица данных. Вы также решаете вместо экспорта в PDF теперь экспортировать простые изображения JPEG.
Внезапно вы вспоминаете принцип единой ответственности и осознаете свою ошибку! Вместо одной ответственности у вашего класса три:
- Собираем данные для отчета
- Создайте форматирование отчета
- Экспортировать отчет
Здесь важно кое-что понять.
Единая ответственность определяется как «одна причина для изменений», а не как «одна ответственность». Вы можете возразить, что «создание отчетов» — это одна из обязанностей, и будете правы. Зачем тогда разбивать его на несколько классов?
Существенным отличием является «причина изменения». Теперь у каждого из этих трех классов есть одна причина для изменений: изменить сбор данных, изменить форматирование отчета и экспортировать его. Это проще поддерживать и отлаживать, чем один класс с тремя причинами для изменения…
Вы можете принимать решения, основываясь на принципе единой ответственности. Когда вам нужно сделать сетевой запрос, вы можете создать новый класс, поскольку, хотя он и необходим для сбора данных для отчета, это другая ответственность, поскольку он инкапсулирует изменения другого типа.
Принцип единой ответственности помогает определить границы компонентов. Вы можете себе представить, что меньший по размеру и более простой компонент легче поддерживать и отлаживать. Но что слишком мало?
Точно так же некоторые компоненты становятся довольно большими — много строк кода — но как узнать, какие из них слишком велики? Что является сигналом о необходимости переместить часть этого кода в другое место? В этом поможет эвристика — принцип единой ответственности.
Принцип единой ответственности действителен не только для классов. Думаю об этом:
- Приложение должно решать одну проблему, и только одну. Нашли новую проблему? Создайте новое приложение.
- Библиотека кода должна выполнять одну задачу. Нужно выполнить еще одну задачу? Напишите новую библиотеку.
- Компонент должен инкапсулировать одну ответственность. Хотите, чтобы компонент мог делать больше? Закодируйте новый компонент.
Даже в жизни полезно делать только одно дело за раз…
Итак, теперь вы знаете: принцип единой ответственности. Почему бы вам не начать применять это в своих проектах приложений? Подумайте об архитектуре вашего приложения, его компонентах и выясните, соответствуют ли они принципам SOLID.
