Please enable JavaScript.

Coggle requires JavaScript to display documents.

Управление сложностью ПО - Coggle Diagram

- - - - Менее устойчивые компоненты должны зависеть от более
      - В зависимостях не должно быть циклов
      - Принцип, аналогичный DIP
    - - Принцип, аналогичный SRP
      - У пакета должна быть версия
      - Принцип, аналогичный ISP
  - - - Класс должен содержать в себе все, что меняется в одно время по потребностям одной группы лиц
      - Ограничивает декомпозицию, чтобы изменения не затрагивали много модулей
      - Тесно связанное - рядом
      - В хорошо запроектированных системах все классы имеют понятную неразмытую ответственность
    - - Только корректный Override при наследовании, чтобы не сломать полиморфный клиентский код
    - - Клиент не должен зависеть (и перекомпилироваться) от неиспользуемых частей интерфейса
      - Каждый клиент определяет свой интерфейс, сервер не должен показывать всем все
      - Маленький интерфейс легко mock'ать при тестировании
    - - Абстрактная сущность определяет используемый интерфейс, а конкретная сущность зависимо реализует его
    - - При добавлении функционала должен добавляться новый код, а не модифицироваться существующий
      - Представлять, как код заработает при разных требованиях, не доходя до избыточной общности
- - - - Решения о выборе деталей легко отложить и поменять
      - Бизнес-правила задают структуру проекта. Архитектура должна быть "кричащей"
      - Бизнес-правила (политика) не зависят от деталей (механика)
      - UML-диаграммы для проверки правильной организации зависимостей
      - Фреймворк - деталь
  - - - В очевидных местах тратят время читающего
      - Использовать для документирования API и пояснения костылей
    - - Компактный код для чтения опытными, общепринятый - новичками
      - Новичок видит много мелких деталей, опытный - мало крупных
      - Количество смыслов <= 5 в модуле
  - - - APO (избегать преждевременной оптимизации)
      - Дополнительные абстракции усложняют код, но могут никогда не потребоваться (overhead)
      - Не разделять приложение на сервисы с самого начала, но поддерживать легкость разделения
- - - - Предоставляет метод для смены состояния (переход)
      - Структура, пребывающая в одном из возможных состояний
  - - - Расширяет API
      - Позволяет реализовать через агрегацию наследование, в т.ч. множественное
    - - Предоставляет альтернативный API
    - - Не изменяет API, добавляет функциональность
    - - Упрощает API
- - - - Нет гарантий защиты от NPE
      - Сильнее уязвим для выполнения вредоносного кода
      - Сложнее тестировать