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

Формулировка: не должно быть больше одной причины для изменения класса

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

Примеры

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

1. Active Record

Проблема

Совсем недавно в качестве ORM я использовал MyGeneration. Суть этой ORM состоит в том, что по таблицам базы данных, она генерирует бизнес-сущности. Возьмем для примера сущность пользователя - Account. Сценарий использования выглядит так:

// создание пользователя
Accounts account = new Accounts();
account.AddNew();
account.Name = "Name";
account.Save();
 
// загрузка объекта по Id
Accounts account = new Accounts()
account.LoadByPrimaryKey(1);
 
// загрузка связной коллекции при обращении к свойству объекта
var list = account.Roles;

Шаблон Active Record может быть успешно использован в небольших проектах с простой бизнес-логикой. Практика показывает, что когда проект разрастается, то из-за смешанной логики внутри доменных объектов возникает много дублирования в коде и непредвиденных ошибок. Обращения к базе данных довольно сложно проследить, когда они скрыты, например, за свойством объекта account.Roles.

В данном случае объект Account имеет несколько ответственностей:

1. является объектом домена и хранит бизнес-правила, например, связь с коллекцией ролей
2. является точкой доступа к базе данных

Решение

Простым и действенным выходом является использование шаблона Repository. Хранилищу AccountRepository мы оставляем работу с базой данных и получаем «чистый» доменный объект.

// создание пользователя
var account = new Account();
account.Name = "Name";
accountRepository.Save(account);
 
// загрузка пользователя по Id
var account = accountRepository.GetById(1);
 
// загрузка со связной коллекцией
// пример из LLBLGen Pro
var account = accountRepository.GetById(1, new IPath[]{new Path<Account>(Account.PrefetchPathRoles)});

2. Валидация данных

Проблема

Если вы сделали хотя бы один проект, то перед вами наверняка стояла проблема валидации данных. Например, проверка введенного адреса эл. почты, длины имени пользователя, сложности пароля и т.п. Для валидации объекта резонно возникает первая реализация:

public class Product
{
    public int Price { get; set; }
 
    public bool IsValid()
    {
        return Price > 0;
    }
}
 
// проверка на валидность
var product = new Product { Price = 100 };
var isValid = product.IsValid();

Такой подход является вполне оправданным в данном случае. Код простой, тестированию поддается, дублирования логики нет.

Теперь наш объект Product начал использовать в некоем CustomerService, который считает валидным продукт с ценой больше 100 тыс. рублей. Что делать? Уже сейчас понятно, что нам придется изменять наш объект продукта, например, таким образом:

public class Product
{
    public int Price { get; set; }
 
    public bool IsValid(bool isCustomerService)
    {
        if (isCustomerService == true)
            return Price > 100000;
 
        return Price > 0;
    }
}
 
// используем объект продукта в новом сервисе
var product = new Product { Price = 100 };
var isValid = product.IsValid(true);

Решение

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

public interface IProductValidator
{
    bool IsValid(Product product);
}
 
public class ProductDefaultValidator : IProductValidator
{
    public bool IsValid(Product product)
    {
        return product.Price > 0;
    }
}
 
public class CustomerServiceProductValidator : IProductValidator
{
    public bool IsValid(Product product)
    {
        return product.Price > 100000;
    }
}
 
public class Product
{
    private readonly IProductValidator validator;
 
    public Product() : this(new ProductDefaultValidator())
    {
    }
 
    public Product(IProductValidator validator)
    {
        this.validator = validator;
    }
 
    public int Price { get; set; }
 
    public bool IsValid()
    {
        return validator.IsValid(this);
    }
}
 
// обычное использование
var product = new Product { Price = 100 };
 
// используем объект продукта в новом сервисе
var product = new Product (new CustomerServiceProductValidator()) { Price = 100 };

Имеем объект Product отдельно, а любое количество всяческих валидаторов отдельно.

В дополнение хочу посоветовать книгу Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET. В ней очень подробно рассмотрен вопрос валидации данных.

3. God object

Проблема

Предел нарушения принципа единственности ответственности – God object. Этот объект знает и умеет делать все, что только можно. Например, он делает запросы к базе данных, к файловой системе, общается по протоколам в сеть и содержить тонну бизнес-логики. В пример приведу объект, который называется ImageHelper:

public static class ImageHelper
{
    public static void Save(Image image)
    {
        // сохранение изображение в файловой системе
    }
 
    public static int DeleteDuplicates()
    {
        // удалить из файловой системы все дублирующиеся изображения и вернуть количество удаленных
    }
 
    public static Image SetImageAsAccountPicture(Image image, Account account)
    {
        // запрос к базе данных для сохранения ссылки на это изображение для пользователя
    }
 
    public static Image Resize(Image image, int height, int width)
    {
        // изменение размеров изображения
    }
 
    public static Image InvertColors(Image image)
    {
        // изменить цвета на изображении
    }
 
    public static byte[] Download(Url imageUrl)
    {
        // загрузка битового массива с изображением с помощью HTTP запроса
    }
 
    // и т.п.
}

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

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

Решение

Решением является разделить этот класс по принципу единственности ответственности: один класс на одну ответственность.

public static class ImageFileManager
{
    public static void Save(Image image)
    {
        // сохранение изображение в файловой системе
    }
 
    public static int DeleteDuplicates()
    {
        // удалить из файловой системы все дублирующиеся изображения и вернуть количество удаленных
    }
}
 
public static class ImageRepository
{
    public static Image SetImageAsAccountPicture(Image image, Account account)
    {
        // запрос к базе данных для сохранения ссылки на это изображение для пользователя
    }
}
 
public static class Graphics
{
 
    public static Image Resize(Image image, int height, int width)
    {
        // изменение размеров изображения
    }
 
    public static Image InvertColors(Image image)
    {
        // изменить цвета на изображении
    }
}
 
public static class ImageHttpManager
{
    public static byte[] Download(Url imageUrl)
    {
        // загрузка битового массива с изображением с помощью HTTP запроса
    }
}

Этот пост входит в серию Принципы проектирования классов (S.O.L.I.D.):

• Принцип единственности ответственности (The Single Responsibility Principle)
• Принцип открытости/закрытости (The Open Closed Principle)
• Принцип замещения Лисков (The Liskov Substitution Principle)
• Принцип разделения интерфейса (The Interface Segregation Principle)
• Принцип инверсии зависимости (The Dependency Inversion Principle)

---

Ссылки

Глава «The Single Responsibility Principle» из книги Роберта Мартина «Agile Principles, Patterns, and Practices in C#»

InfoQ: Making Roles Explicit

LosTechies: Single Responsibility Principle

CodeBetter: Single Responsibility Principle

DimeCasts: Creating SOLID Code: Single Responsibility Principle