SOLID: Object-Oriented Design Principles

Кирилл Корняков (Itseez, ННГУ)
Октябрь 2015

Объектно-ориентированный дизайн

• Уровни абстракции
  • Исходный код
  • Объектно-ориентированный дизайн
  • Архитектура
• Три концепции ООП
  • Инкапсуляция (хорошо!)
  • Полиморфизм (хорошо!)
  • Наследование (плохо?!)

Зависимости — корень многих проблем!

Болезни дизайна

• Жесткость (Rigidity)
  • Единственное изменение требует каскада изменений в других модулях
• Хрупкость (Fragility)
  • Свойство программы повреждаться во многих местах при внесении единственного изменения
• Неподвижность (Immobility)
  • Сложность переиспользования кода в других системах / подсистемах
• Вязкость (Viscosity)
  • Когда неправильное решение дешевле правильного
  • Существуют вязкость программы и окружения
• Ненужная сложность
• Ненужные повторения
• Непрозрачность

Примеры проблем

• Долгая компиляция и медленные тесты
• Использование глобальных переменных
• Класс с несколькими ответственностями
• Использование float для представления денег при переходе с рублей на доллары
• Использование if/else вместо полиморфизма

SOLID principles

• SRP: Single Responsibility Principle
• OCP: Open/Closed Principle
• LSP: Liskov Substitution Principle
• ISP: Interface Segregation Principle
• DIP: Dependency Inversion Principle

Single Responsibility Principle

Single Responsibility Principle

Программные сущности должны иметь только одну ответственность.

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

Пример

Пример

SOLID principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Open/Closed Principle

"Программные сущности должны быть открыты для расширения,
но закрыты для модификации."

Б. Мейер, 1988 / Р. Мартин, 1996

Нет ли здесь противоречия? Как этого можно добиться?

Метафора OCP

Пример c явной зависимостью

ReportFormat format = TXT;
Reporter reporter(format);
...
reporter.getAnnualReport();

class Reporter {
    private TxtPrinter txtPrinter;
    private XmlPrinter xmlPrinter;

    Reporter(ReportFormat format) {
        if (format == TXT)
            txtPrinter = new TxtPrinter();
        else if (format == XML)
            xmlPrinter = new XmlPrinter();
    }

    void getAnnualReport() {
        AnnualReport report = new AnnualReport();

        if (txtPrinter)
            txtPrinter.print(report);
        else if (xmlPrinter)
            xmlPrinter.print(report);
    }
}

Пример с неявной зависимостью

IPrinter printer = new TxtPrinter();
Reporter reporter(printer);
...
reporter.getAnnualReport();

class Reporter {
    IPrinter printer;

    Reporter(IPrinter printer) {
        this.printer = printer;
    }

    void getAnnualReport() {
        AnnualReport report = new AnnualReport();
        printer.print(report);
    }
}

Стратегическое закрытие

"Ни одна значительная программа не может быть на 100% закрытой"

Р. Мартин, 1996

OCP: полезные советы

• Паттерны Стратегия (Strategy) и Шаблонный Метод (Template Method)
• Инкапсуляция: стоит хранить данные в private/protected полях
• Нет глобальным переменным
• Скрываем неподдерживаемую функциональность
• Проверка типов времени исполнения (RTTI) опасна

SOLID principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Dependency Inversion Principle

Абстракции не должны зависеть от деталей.
Детали должны зависеть от абстракций.

Procedural Architecture

Procedural Architecture

Object-Oriented Architecture

Object-Oriented Architecture

Пример

enum OutputDevice { PRINTER, DISK };

void Copy(OutputDevice device) {
    int c;
    while ((c = ReadKeyboard()) != EOF)
        if (device == PRINTER)
            WritePrinter(c);
        else
            WriteDisk(c);
}

Пример

void Copy(Writer writer) {
    int c;
    while ((c = ReadKeyboard()) != EOF) {
        writer.Write(c);
    }
}

Пример

public interface IReader {
   char Read();
}
public interface IWriter {
   void Write(char c);
}

void Copy(IReader reader, IWriter writer) {
    int c;
    while ((c = reader.Read()) != EOF) {
        writer.Write(c);
    }
}

В чем преимущества такого подхода?

Внедрение зависимости (Dependency Injection)

• Внедрение зависимости — процесс предоставления внешней зависимости программному компоненту.
• Часть объектов в программе по-прежнему создается обычным способом языка программирования, часть — создается контейнером на основе предоставленной ему конфигурации.
• Конфигурационный файл описывает какие конкретно реализации должны быть инициализированы. В программный код изменения не вносятся!

Wikipedia

Пример (создание вручную)

public class MyApplication
{
    public static void main(String[] args)
    {
        // Явное конструирование
        ICar car = new DefaultCarImpl();

        // Использование
        car.setPedalPressure(5);
        float speed = car.getSpeed();
    }
}

Пример с использованием DI-фреймворка

public class MyApplication
{
    public static void main(String[] args)
    {
        // Неявное конструирование
        Service service = (Service)DependencyManager.get("CarBuilderService");
        ICar car = (ICar)service.getService(Car.class);

        // Использование
        car.setPedalPressure(5);
        float speed = car.getSpeed();
    }
}

Конфигурационный файл

    <service-point id="CarBuilderService">
        <invoke-factory>
            <construct class="Car">
                <service>DefaultCarImpl</service>
                <service>DefaultEngineImpl</service>
            </construct>
        </invoke-factory>
    </service-point>

SOLID principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Interface Segregation Principle

Interface Segregation Principle

"Клиенты не должны зависеть от интерфейсов, которые они не используют"

Р. Мартин, 1996

Пример

Пример namespace utils.

Пример

Cлишком «толстые» интерфейсы необходимо разделять на более маленькие и специфические.

SOLID principles

• Single Responsibility Principle
• Open/Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

Liskov Substitution Principle

Композиция vs Наследование

• По прошествии лет люди осознали, что зачастую
  вреда от наследования обычно больше, нежели пользы,
  и на самом деле наследование нужно лишь в исключительных случаях.
• Рекомендации
  • Не должно является способом переиспользования кода
  • Предпочитайте композицию наследованию
  • Старайтесь ограничиться реализацией интерфейсов
  • Должно обеспечивать полиморфное использование (DIP)
• Критерии корректности наследования
  • "Is A" критерий
  • LSP принцип является важнейшим критерием
    для оценки качества принимаемых решений
    при построении иерархий наследования.

Liskov Substitution Principle

"Наследование должно гарантировать,
что любое свойство, справедливое для супертипа,
должно быть справедливо и для наследников."

Б. Лисков, 1987

Пример

Базовый класс

class Bird {                    // Есть клюв, крылья...
    public virtual void fly();  // Птица может летать
};

Наследник 1: Попугай

class Parrot : Bird {     // Попугай – птица
    public override void fly() { ... }
};

Метод, полиморфно использующий птицу

void PlayWithBird (Bird bird) {
    bird.Fly();
}

Пример

Метод, полиморфно использующий птицу

void PlayWithBird (Bird bird) {
    bird.Fly();
}

Наследник 2: Пингвин

class Penguin : Bird {
    public override void fly() {
        throw "Пингвины не летают!";
    }
};

• Внимание: с добавлением пингвина ранее корректный PlayWithBird стал неправильным!
• Что нужно сделать, чтобы код стал корректным с текущей иерархией наследования?
• Чем плохо такое "решение"?

Пример — решение

class Bird {
    // есть клюв, крылья...
};

class FlyingBird : Bird {
    public virtual void fly();  // птица может летать
};

class Parrot : FlyingBird {     // Попугай – летающая птица
 public override void fly() { ... }
};

class Penguin : Bird {
    // ...
};

Задача: квадрат — это прямоугольник?

class Rectangle {
    private double width;
    private double height;

    public void SetWidth(double w);
    public void SetHeight(double h);

    public double GetArea();
}

class Square : Rectangle {...}

void Adjust(Rectangle rect)
{
  rect.SetWidth(5);
  rect.SetHeight(4);

  // Чему будет равна площадь?
  double area = rect.GetArea();
}

Закон Деметры

• Метод М объекта О имеет право вызывать методы только у:
  • аргументов М
  • объектов, созданных внутри М
  • самого О
  • объектов-членов О
  • глобальных переменных, доступных О, в пределах М
• Вопрос: а чего делать нельзя?
• Закон одной точки
  • a.Method(), но не a.b.Method()
  • player.Accounts[0].Balance.Sum(a => a.ConvertTo(“RUR”));
  • player.AvailableCash()

Закон Деметры

• Аналогия из жизни: eсли Вы хотите, чтобы собака побежала, глупо командовать ее ногами, лучше отдать команду собаке, а она уже разберётся со своими ногами сама.
• Объект должен иметь как можно меньше представления о структуре и свойствах чего угодно (включая собственные подкомпоненты).
• Закон Деметры является специальным случаем слабой связанности (loose coupling).
• Метафора про подлодку и шпионов.

Wikipedia

Следование принципам

• Принципы используются только при наличии "болезней",
  если их нет, принципами не стоит увлекаться.
• Нужно следовать правилу первой пули.
  Интерфейсы вводятся только в том момент, когда они действительно нужны.

Контрольные вопросы

План ответа про каждый из SOLID принципов:

1. Формулировка, раскрыть все слова названия.
2. Как достигается.
3. Негативные последствия нарушения. К каким "болезням" дизайна может привести нарушение принципа?

Вопросы:

1. Термины: жесткость, хрупкость, неподвижность, вязкость
2. SRP
3. OCP
4. LSP
5. ISP
6. DIP
7. Закон Деметры (что можно, чего нельзя)

Дополнительные вопросы

• Как влияет практика TDD на соблюдение принципов SOLID?

Следуй SOLID!

Спасибо!

Вопросы?