digital-garden/dev/architecture/Single Responsibility Principle.md

aliases	tags	date
SRP принцип единственной ответственности Single Responsibility единственная ответственность единственной ответственности	maturity/🌱	2024-09-27

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

[!EXAMPLE] Причина для изменения Под "причиной для изменения" подразумевается аспект функциональности, который может измениться из-за изменения бизнес-требований. Например, класс, управляющий пользователями, должен модифицироваться только при изменении требований к управлению пользователями, но не из-за обновлений в логике отправки уведомлений.

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

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

Преимущества:

1. Упрощенная поддержка: Изменения в одной части системы не влияют на другие, снижая риск побочных эффектов.
2. Повышенная переиспользуемость: Узкоспециализированные классы можно легко применять повторно. Например, класс EmailService можно использовать в разных модулях для отправки уведомлений без доработок.
3. Улучшенная читаемость: Четко определенные обязанности классов упрощают понимание кода для текущих и будущих разработчиков.
4. Снижение риска ошибок: Разделение ответственности на изолированные компоненты помогает уменьшить вероятность ошибок, так как изменения в одной области не затрагивают другую.
5. Упрощение тестирования: Можно протестировать независимо каждый компонент.

Пример нарушения SRP

Рассмотрим класс, который одновременно управляет данными пользователя и отправляет сообщения по электронной почте:

public class UserManager {
    private String userData;

    public void updateUser(String data) {
        // Логика управления пользователем
        this.userData = data;
    }

    public void sendEmail(String email, String message) {
        // Логика отправки сообщений
        System.out.println("Sending email to: " + email);
    }
}

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

Разделите обязанности на отдельные классы:

public class UserService {
    public void updateUser(String data) {
        // Логика управления пользователем
    }
}

public class EmailService {
    public void sendEmail(String email, String message) {
        // Логика отправки сообщений
    }
}

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

---

Мета информация

Область:: ../../meta/zero/00 Архитектура ПО Родитель:: SOLID Источник:: Создана:: 2024-09-27 Автор::

Дополнительные материалы

• Bounded Context

Дочерние заметки