Принципы проектирования архитектуры
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.
Одним из важных аспектов для построения гибкой архитектуры является распределение ответственности между компонентами системы. В основании предложенных принципов лежит работа с ответственностью, потому что именно с ней мы работаем в коде, распределяя обязанности и задачи между компонентами.
Здесь рассмотрены проблемы некоторых популярных принципов и предложена им альтернатива.
Следует отметить, что данный набор принципов, как и все другие, бесполезен, если не понимать, каким критериям должна соответствовать гибкая архитектура, а также без понимания, какие инструменты управления ответственностью существуют.
Проблемы SOLID
SOLID принципы также предназначены для построения гибкой архитектуры ПО. Однако они обладают рядом недостатков:
- Неочевидность терминов, используемых в расшифровке
- Малое внимание к ответственности компонентов, из-за чего открывается большой простор для спекуляций
- Сложные формулировки
- Прямая ориентация на ООП, на ФП есть только неявная
- Отсуствие балансирующих принципов
Проблемы DRY, KISS, YAGNI
Данные принципы прекрасны в своей простоте. Они ориентированы на определения областей ответственности, однако это не указано в их расшифровке.
Переработанный перечень принципов
Некоторые из предложенных принципов являются переработкой уже существующих в контексте распределения ответственности. Их цель - обеспечить не меньшую полноту по сравнению с предшественниками и решить их проблемы. Здесь они представлены в тезисном виде.
Важные определения
Ответственность здесь представляется обязанностями и задачами, которые должен выполнять компонент.
Делегирование - передача части ответственности другому компоненту
Вмешательство - неуместное участие в процессе выполнения задачи, создание помех, которые уменьшают понятность кода для программиста.
Определение области ответственности - это интерфейс, определение класса, функции, или части тела функции.
Перечень принципов
Essence Defines Responsibility
Компоненты, ближе к сути предметной области, определяют область ответственности компонентов, которые дальше от неё
No Duplicate Responsibility Principle
Дублирование определений области ответственности компонентов должно устраняться
Delegate Responsibility Principle
Компонент должен делегировать часть ответственности, если это упростит использование системы
Reversive Delegate Responsibility Principle
Компонент должен возвращать часть или полностью отказываться от ответственности, если это упростит использование системы
Isolate Responsibility Principle
Компонент не должен допускать вмешательства в свою область ответственности, а также сам не должен вмешиваться в область ответственности другого компонента
Assign Necessary Orders Principle
Компонент должен поручать только те обязанности и задачи, которые необходимы для его работы
Complete All Orders Principle
Компонент должен выполнять все обязанности в своей области ответственности
Complete Necessary Orders Principle
Компонент должен брать на себя только те обязанности и задачи, которые ему поручили
Итог
Использование данного набора принципов увеличит вероятность удобного распределения ответственности. Однако слепое их применение вредно. Критерии и инструменты могут помочь не забыть о назначении этих принципов.