arch
# Чистая архитектура
## Парадигмы программирования
- Структурное программирование (органичение на прямую передачу управления)
- Объектно-оориентироованное программирование (органичение на косвенную передачу управления)
- Функциональноео программирование (органичение на присваивание)
Им соответствуют три аспекта строительства архитектуры: функциональность,разделение компонентов, управление данными.
### Структурное программировоание
Дейкстра, 1968
Любую программу можно написать, используя 3 структуры: последовательность, выбор, итерация.
Инструкция перехода `goto` мешает рекурсивному разложению модулей на меньшие единицы, препятствует применению принципа «разделяй и властвуй»
`goto` заменяется на `if/then/else` и `do/while/until`
### Объектно-ориентированное программирование
Оле-Йохан Даль и Кристен Нюгор, 1966
- Инкаспуляция ?
- Наследование ?
- Полиморфизм !
Архитектура плагинов; реализация классов/модулей, использующих одинаковый интерфейс
Инверсия зависимостей (стр. 64)
Любую зависимость исходного кода инвертировать, асболютный контроль над направлением всех зависимостей
Независимость развертывания компонентов
### Функциональное программирование
На будущее:
Многопточность, состояние гонки (race condition), взаимоблокировки (deadlocks)
Ограничение изменяемости, транзакционная память
Правильно организованные приложения должны делиться на компоненты, имеющие и не имеющие изменяемых переменных
> Представьте банковское приложение, управляющее счетами клиентов. Оно изменяет счета, когда выполняются операции зачисления или списания средств. Теперь вообразите, что вместо сумм на счетах мы сохраняем только информацию об операциях. Всякий раз, когда кто-то пожелает узнать баланс своего счета, мы просто выполняем все транзакции с состоянием счета от момента его открытия. Эта схема не требует изменяемых переменных.
Регистрация событий (event sourcing) — стратегия, когда сохраняются транзакции, а не состояние.
Если транзацкий становится очень много (пример выше), можно сохранять промежуточные состояния
Таким образом, приложения можно сделать полностью функциональным
## Приципы дизайна
Принципы **SOLID** определяют, как объединять функции и структуры данных в классы и как эти классы должны сочетаться друг с другом.
Цель: создать программные структуры, которые
- терпимы к изменениям,
- просты и понятны,
- образуют основу для компонентов, которые могут использоваться во многихпрограммных системах
[Solid JavaScript](https://getinstance.info/search/?tags=&how=r&q=solid+принципы)
- **SRP** (Single Responsibility Principle) — принцип единственой ответственности
Модуль имеет только одну причину для изменения
- **OCP** (Open-Closed Principle) — принцип открытости/закрытости
Простая для изменения программа должна изменяться путем добавления кода, а не изменением усществующего кода
- **LSP** (Liskov Substitution Principle) — прицип подстановки Барбары Лисков
Взаимозаменяемые части системы должны соответствовать контракту (интерфейсу), который позволяет заменять эти части друг другом.
- **ISP** (Interface Segregation Principle) — прицип разделения интерфейсов
Избегать зависимости от всего, что не используется.
- **DIP** (Dependency Inversion Principle) — принцип инверсии зависимости
Код, реализующий высокоуровневую политику, не должен зависеть от кода, реализующего низкоуровневые детали.
### SRP
У модуля должен быть только один актор
Разделение кода, предназначенного для обслуживания разных акторов
Проблемы: непреднамеренноое дублирование, слияние
Решение: перемещение функций в разные классы, фасад
[Пример на Хабре](https://habr.com/ru/post/328584/)
### OCP
Cтр. 86
### LSP
Если для каждого объекта o1 типа S существует такой объект o2 типа T, что для всех программ P, определенных в терминах T, поведение P не изменяется при подстановке o1 вместо o2, то S является подтипом T1.
Короче, наследование
Будь добр соблюдать требования, пользоваться одним интерфейсом, не придумывать свой велосипед
### ISP
### DIP
Наиболее гибкими получаются системы, в которых зависимости в исходном коде направлены на абстракции, а не на конкретные реализации.
Стабильными называются такие архитектуры, в которых вместо зависимостей от переменчивых конкретных реализаций используются зависимости от стабильных абстрактных интерфейсов.
- Не ссылайтесь на изменчивые конкретные классы. Ссылайтесь на абстрактные интерфейсы. Шаблон «Абстрактная фабрика»
- Не наследуйте изменчивые конкретные классы
- Не переопределяйте конкретные функции
- Никогда не ссылайтесь на имена конкретных и изменчивых сущностей
## Принципы организации компонентов