Принцип открытости/закрытости

Формулировка: программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения

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

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

Отсюда можно сделать вывод, что нашей целью является разработка системы, которая будет достаточно просто и безболезненно меняться. Другими словами, система должна быть гибкой. Например, внесение изменений в библиотеку общую для 4х проектов не должно быть долгим («долгим» является разным промежутком времени для конкретной ситуации) и уж точно не должно вести к изменениям в этих 4х проектах.

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

Примеры

Без абстракций

Проблема

Самый простой пример нарушения принципа открытости/закрытости – использование конкретных объектов без абстракций. Предположим, что у нас есть объект SmtpMailer. Для логирования своих действий он использует Logger, который записывает информацию в текстовые файлы.

public class Logger
{
    public void Log(string logText)
    {
        // сохранить лог в файле
    }
}
 
public class SmtpMailer
{
    private readonly Logger logger;
 
    public SmtpMailer()
    {
        logger = new Logger();
    }
 
    public void SendMessage(string message)
    {
        // отсылка сообщения
 
        logger.Log(string.Format("Отправлено '{0}'", message));
    }
}

И тоже самое происходит в других классах, которые используют Logger. Такая конструкция вполне жизнеспособна до тех, пока мы не решим записывать лог SmptMailer'a в базу данных. Для этого нам надо создать класс, который будет записывать все логи не в текстовый файл, а в базу данных:

public class DatabaseLogger
{
    public void Log(string logText)
    {
        // сохранить лог в базе данных
    }
}

А теперь самое интересное. Мы должны изменить класс SmptMailer из-за изменившегося бизнес-требования:

public class SmtpMailer
{
    private readonly DatabaseLogger logger;
 
    public SmtpMailer()
    {
        logger = new DatabaseLogger();
    }
 
    public void SendMessage(string message)
    {
        // отсылка сообщения
 
        logger.Log(string.Format("Отправлено '{0}'", message));
    }
}

Но ведь по принципу единственности ответственности не SmptMailer отвечает за логирование, почему изменения дошли и до него? Потому что нарушен наш принцип открытости/закрытости. SmptMailer не закрыт для модификации. Нам пришлось его изменить, чтобы поменять способ хранения его логов.

Решение

В данном случае защитить SmtpMailer поможет выделение абстракции. Пусть SmtpMailer зависит от интерфейса ILogger:

public interface ILogger
{
    void Log(string logText);
}
 
public class Logger : ILogger
{
    public void Log(string logText)
    {
        // сохранить лог в файле
    }
}
 
public class DatabaseLogger : ILogger
{
    public void Log(string logText)
    {
        // сохранить лог в базе данных
    }
}
 
public class SmtpMailer
{
    private readonly ILogger logger;
 
    public SmtpMailer(ILogger logger)
    {
        this.logger = logger;
    }
 
    public void SendMessage(string message)
    {
        // отсылка сообщения
 
        logger.Log(string.Format("Отправлено '{0}'", message));
    }
}

Теперь смена логики логирования уже не будет вести к модификации SmtpMailer'а.

Проверка типа абстракции

Проблема

Этот пример в разных вариациях все не раз видели в коде. Его хоть в рамку можно вешать, как самое популярное нарушение проектирования. У нас есть иерархия объектов с абстрактным родительским классом AbstractEntity и класс Repository, который использует абстракцию. При этом вызывая метод Save у Repository мы строим логику в зависимости от типа входного параметра:

public abstract class AbstractEntity
{
}
 
public class AccountEntity : AbstractEntity
{
}
 
public class RoleEntity : AbstractEntity
{
}
 
public class Repository
{
    public void Save(AbstractEntity entity)
    {
        if (entity is AccountEntity)
        {
            // специфические действия для AccountEntity
        }
        if (entity is RoleEntity)
        {
            // специфические действия для RoleEntity
        }
    }
}

Из кода видно, что объект Repository придется менять каждый раз, когда мы добавляем в иерархию объектов с базовым классом AbstractEntity новых наследников или удаляем существующих. Условные операторы будут множится в методе Save и тем самым усложнять его.

Решение

Конкретизируя классы методом is или typeof мы должны сразу понять, что наш код начал «попахивать». Чтобы решить данную проблему, необходимо логику сохранения конкретных классов из иерархии AbstractEntity вынести в конкретные классы Repository. Для этого мы должны выделить интерфейс IRepository и создать хранилища AccountRepository и RoleRepository:

public abstract class AbstractEntity
{
}
 
public class AccountEntity : AbstractEntity
{
}
 
public class RoleEntity : AbstractEntity
{
}
 
public interface IRepository<T> where T : AbstractEntity
{
    void Save(T entity);
}
 
public class AccountRepository : IRepository<AccountEntity>
{
    public void Save(AccountEntity entity)
    {
        // специфические действия для AccountEntity
    }
}
 
public class RoleRepository : IRepository<RoleEntity>
{
    public void Save(RoleEntity abstractEntity)
    {
        // специфические действия для RoleEntity
    }
}

Теперь наши изменения будут локализованы в конкретных объектах.

Этот пост входит в серию Принципы проектирования классов (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)

---

Ссылки

R. Martin: The Open-Closed Principle

К. Бек: The Open/Closed/Open Principle

P&P: The Open Closed Principle

LosTechies: The Open Closed Principle