🎉

2.5. Поэтому и появился (λ) ФОП

 
Итак, если вы прочитали все изложенные выше статьи, то в итоге, получится следующий список пожеланий от парадигмы программирования:
 
  1. Мы хотим, чтобы парадигма помогала нам писать максимальную гибкий код, который мы сможем не рафакторить, а развивать с приходом новых фич.
  1. Мы хотим иметь возможность удобно работать с мутабельными структурами, но иногда обращаться к иммутабельности.
  1. Мы не хотим создавать излишнюю атомарность (изолированность) кода или абстракции.
  1. Мы хотим, чтобы контекстозависмый код находился там, где находится его контекст и не засорял кодовую базу других контекстов.
  1. Мы хотим строить приложения от процессов и при этом держать модели бизнес-логики как можно ближе к исходным данным.
 
Почему нам не подходят:
 
  1. ООП – потому что в нем существует излишняя атомарность, убивающая гибкость кода, потому что он требует кучи дополнительных знаний типа SOLID, DRY и подобных, чтобы работать «нормально», потому что он основан на столпах, которые по итогу стали для него же самого bad-practice, потому что мы итак постоянно склоняемся к Anemic Model, а значит уходим в Процедурное программирование.
  1. Функциональное программирование (ФП) – потому что оно хоть и решает проблемы ООП, но мы не получим основной фичи (распараллеливание вычислений) ФП-оных языков, но при этом получим кучу проблем с поддержкой Монад, Семиграп, Сетоидов, иммутабельности и так далее.
  1. Процедурное программирование (ПП) – потому что оно хоть и решает проблемы ООП и ФП, но оно устарело, потому что в нем нет приёмов и техник, потому что писать по его правилам – опасно и сложно.
 
И именно поэтому появилось Функционально Ориентированное Программирование (ФОП), которое основывается на ПП, но включает в себя все самые лучшие практики, появившиеся в ФП, и не включает то, что не даст нам никаких преимуществ в мультипарадигмальных языках:
 
  1. Разделение Поведения и Данных решает вопрос излишней атомарности кода в ООП и даёт максимальную гибкость программы.
  1. Композиция и Интерфейсный полиморфизм лежат в основе ФОП и являются best-practice даже в ООП.
  1. Программа построена из цепочек / композиции функций, каждая из которых полностью отвечает за свой контекст и использует данные в том виде, в котором мы считаем нужным (будь то чистые структуры данных из БД или их агрегации / проекции для более удобной работы)
  1. В ФОП абсолютно нормально работать с мутабельными структурами, но также мы спокойно можем и использовать иммутабельность и чистые функции
  1. Мы на максимум будем утилизировать функции высшего порядка, каррирование, частичную аппликацию, state scope и другого рода приемы, пришедшие из ФП
 
Как все это использовать, вы узнаете в следующих разделах и начать можете c 🧧 Философии ФОП