В мире разработки программного обеспечения принципы SOLID подсказывают нам, как организовать функции и данные так, чтобы наши коды:

• Терпить изменения
• Быть понятным
• Стать основой компонентов, которые можно использовать во многих программных системах

Термин SOLID — это аббревиатура пяти постулатов дизайна, описанных ниже:

(S) Принцип единой ответственности: «У модуля должна быть одна и только одна причина для изменения»
(O) Принцип открытости/закрытости: «Программный артефакт должен быть открыт для расширения, но закрыт для модификации»
(L) Принцип замены Лискова: «Производный класс должен быть заменяем своим базовым классом»
(I) Принцип разделения интерфейсов: «Класс не должен быть вынужден реализовывать интерфейсы и методы, которые он не будет использовать»
(D) Принцип инверсии зависимостей: «Зависите от абстракций, а не от реализаций»

SOLID и GoLang

SOLID предназначен для объектно-ориентированного программирования, и известно, что GoLang не является языком, принимающим эту парадигму. Однако мы можем использовать ресурсы, которые он предоставляет, для соответствия методологии ООП. Например, в Go нет поддержки наследования, но эту идею можно компенсировать поддержкой композиции. Аналогично, тип полиморфизма можно создать с помощью интерфейсов.

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

Принцип единой ответственности (SRP)

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

Выше у нас есть структура, которую мы называем userService. Он имеет два свойства: db, которое отвечает за связь с реляционной базой данных, и amqpChannel, которое обеспечивает связь со службой обмена сообщениями RabbitMQ.

UserService реализует метод Create. В рамках этого метода мы сохраняем полученную информацию о пользователе в базе данных, а затем публикуем данные в RabbitMQ.
Видно, что ответственность метода Create в userService не одна, а две: хранение информации в базе данных и публикация сообщения в очереди RabbitMQ.

Это может привести к ряду проблем, например:

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

В следующем коде мы модифицируем структуру для соблюдения SRP. Посмотрите:

Обратите внимание, что мы разделили обязанности на три отдельные части: репозиторий UserRepository для сохранения пользователя в базе данных, издатель UserPublisher для отправки сообщения в RabbitMQ и сервис UserService, который управляет этими двумя операциями.

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

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

Чтобы применить SRP в этом примере, мы также реализовали некоторые другие принципы SOLID:

• Принцип разделения интерфейсов (ISP): каждый интерфейс представляет собой единую ответственность. И UserRepository, и UserPublisher — это интерфейсы, имеющие только один метод, каждый из которых представляет одну ответственность.
• Принцип инверсии зависимостей (DIP): структура userService зависит от абстракций (интерфейсов), а не от конкретных реализаций, то есть ей неизвестна конкретная реализация UserRepository и UserPublisher, только интерфейсы, которые они реализуют.
• Принцип открытости/закрытости (OCP): код открыт для расширения, поскольку новые репозитории или издатели можно легко добавлять без изменения userService.

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

Увидимся позже, ребята!

Использованная литература:
SOLID: первые 5 принципов объектно-ориентированного проектирования
Блог Clean Coder — принцип единой ответственности