25 августа 2016
7905
На недавно был задан вопрос, который ИМХО стоит вашего внимания: ?. Ниже представлен немного более развернутая версия моего ответа.
На недавно был задан вопрос, который ИМХО стоит вашего внимания: ?. Ниже представлен немного более развернутая версия моего ответа.
Разные принципы проектирования направлены на решение противоречащих друг другу задач проектирования. Можно сказать, что разные принципы «тянут» дизайн в разные стороны и нужно найти правильный вектор, наиболее полезный в данном конкретном случае. SRP толкает в стороны простого решения, а OCP – в сторону изоляции компонентов, а DIP – направлен на построение правильных отношений между типами.
Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.
Но такое отношение между принципами не является фиксированным. Для простого случая выделение иерархии фигур для рисования является нарушением SRP, поскольку «рисование» в первой итерации может заключаться в выводе текста на консоль и размазывание этой информации по нескольким классам будет избыточным. Но по мере усложнения решения, появление иерархии наследования будет оправданной с точки зрения SRP, поскольку сложность отображения каждой отдельной фигуры будет столь высокой, что понятие «ответственности» тоже поменяется. Если вначале «единой ответственностью» было отображение всех фигур, то теперь одна ответственность будет разбита на множество: «отображение круга», «отображение квадрата» и т.п.
Принцип YAGNI (You Aren’t Gonna Need It) – это более фундаментальный принцип («принцип высшего порядка» или «метапринцип»), который поможет понять, когда следовать принципам/паттернам/правилам, а когда нет.
В основе принципа YAGNI лежит несколько наблюдений:
1. Программисты, как и люди в целом, плохо предсказывают будущее.
2. Затраты, сделанные сейчас могут быть оправданными или неоправданными в будущем.
3. Ни одно гибкое решение не будет достаточно гибким.
Эти наблюдения приводят к следующим выводам: попытка создать гибкое решение на ранних стадиях разработки обречено на создание переусложненного решения. Связано это с тем, что на ранних этапах еще не известно, какие именно изменения в системе потребуются, и просто не понятно, где «подстилать солому» для будущих изменений.
Поскольку на ранних этапах мы не знаем, какая именно гибкость нужна, мы заложим гибкость не там, где нужно: мы предусмотрим замену слоя доступа к данным, но из-за «дырявых абстракций», мы все равно залочим решение на определенной базе данных, или же такая гибкость просто никогда не понадобиться. Мы создадим «фреймворк» парсинга аргументов командной строки, который будет использоваться в одном приложении, а стоимость прикручивания его в другое приложение будет таким большим, что никто этим заниматься не будет.
Хороший дизайн заключается в простом решении, когда изменения требований ведут к линейным трудозатратам.
Проще всего добиться этого путем эволюционного дизайна: мы начинаем с разбиения системы на крупные компоненты, но не занимаемся выделением лишних уровней абстракции. Не нужны базовые классы, если сейчас нет хотя бы 2-х-3-х наследников. И даже если такие наследники «могут появиться в будущем», то выделить иерархию типов нужно именно тогда, когда это самое будущее настанет.
Существует простая лакмусовая бумажка принципа YAGNI: выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас.
Инвестиции в продуманность интерфейса программирования библиотеки (API) – будут оправданны, поскольку стоимость внесения изменений очень высока. Стоимость же выделения интерфейса/базового класса в приложении является практически одинаковой сегодня или через год. Но через год данное выделение будет более оправданным экономически и практически. Мы не делали лишнюю работу раньше времени, а значит можем сосредоточить усилия на чем-то важным в данный момент. К тому же, через год у нас появится больше информации на предмет того, каким именно должен быть базовый класс или интерфейс, поскольку они будут основаны на реальных, а не воображаемых требованиях.
Решение проблемы по мере поступления позволяет сосредоточиться на задачах, актуальных сегодня и позволяет избежать работы, которая может и не понадобиться совсем.
Разные принципы проектирования направлены на решение противоречащих друг другу задач проектирования. Можно сказать, что разные принципы «тянут» дизайн в разные стороны и нужно найти правильный вектор, наиболее полезный в данном конкретном случае. SRP толкает в стороны простого решения, а OCP – в сторону изоляции компонентов, а DIP – направлен на построение правильных отношений между типами.
Следование одному принципу может привести к нарушению другого. Так, например, любое наследование *можно* рассматривать как нарушение SPR, поскольку теперь за одну ответственность (рисование фигур) отвечает целая группа классов. Принципы DIP и OCP, которые часто требуют наследования, могут привести к появлению дополнительных «швов», т.е. интерфейсов/базовых классов в системе, что, опять-таки, приведет к нарушению SRP и/или ISP.
Но такое отношение между принципами не является фиксированным. Для простого случая выделение иерархии фигур для рисования является нарушением SRP, поскольку «рисование» в первой итерации может заключаться в выводе текста на консоль и размазывание этой информации по нескольким классам будет избыточным. Но по мере усложнения решения, появление иерархии наследования будет оправданной с точки зрения SRP, поскольку сложность отображения каждой отдельной фигуры будет столь высокой, что понятие «ответственности» тоже поменяется. Если вначале «единой ответственностью» было отображение всех фигур, то теперь одна ответственность будет разбита на множество: «отображение круга», «отображение квадрата» и т.п.
Принцип YAGNI (You Aren’t Gonna Need It) – это более фундаментальный принцип («принцип высшего порядка» или «метапринцип»), который поможет понять, когда следовать принципам/паттернам/правилам, а когда нет.
В основе принципа YAGNI лежит несколько наблюдений:
1. Программисты, как и люди в целом, плохо предсказывают будущее.
2. Затраты, сделанные сейчас могут быть оправданными или неоправданными в будущем.
3. Ни одно гибкое решение не будет достаточно гибким.
Эти наблюдения приводят к следующим выводам: попытка создать гибкое решение на ранних стадиях разработки обречено на создание переусложненного решения. Связано это с тем, что на ранних этапах еще не известно, какие именно изменения в системе потребуются, и просто не понятно, где «подстилать солому» для будущих изменений.
Поскольку на ранних этапах мы не знаем, какая именно гибкость нужна, мы заложим гибкость не там, где нужно: мы предусмотрим замену слоя доступа к данным, но из-за «дырявых абстракций», мы все равно залочим решение на определенной базе данных, или же такая гибкость просто никогда не понадобиться. Мы создадим «фреймворк» парсинга аргументов командной строки, который будет использоваться в одном приложении, а стоимость прикручивания его в другое приложение будет таким большим, что никто этим заниматься не будет.
Хороший дизайн заключается в простом решении, когда изменения требований ведут к линейным трудозатратам.
Проще всего добиться этого путем эволюционного дизайна: мы начинаем с разбиения системы на крупные компоненты, но не занимаемся выделением лишних уровней абстракции. Не нужны базовые классы, если сейчас нет хотя бы 2-х-3-х наследников. И даже если такие наследники «могут появиться в будущем», то выделить иерархию типов нужно именно тогда, когда это самое будущее настанет.
Существует простая лакмусовая бумажка принципа YAGNI: выделение лишних абстракций (и любое другое усложнение) оправдано лишь в том случае, если стоимость их выделения в будущем будет существенно дороже, чем сейчас.
Инвестиции в продуманность интерфейса программирования библиотеки (API) – будут оправданны, поскольку стоимость внесения изменений очень высока. Стоимость же выделения интерфейса/базового класса в приложении является практически одинаковой сегодня или через год. Но через год данное выделение будет более оправданным экономически и практически. Мы не делали лишнюю работу раньше времени, а значит можем сосредоточить усилия на чем-то важным в данный момент. К тому же, через год у нас появится больше информации на предмет того, каким именно должен быть базовый класс или интерфейс, поскольку они будут основаны на реальных, а не воображаемых требованиях.
Решение проблемы по мере поступления позволяет сосредоточиться на задачах, актуальных сегодня и позволяет избежать работы, которая может и не понадобиться совсем.