Denys Poltorak Embedded | C++ на DOU.ua
А по поводу парадигм — прошу внимательнее присмотреться к процессу написания адаптера на ФП:
1) У нас есть база, она на выделенном сервере или в облаке.
2) Мы пишем к ней адаптер. Если у нас хоть какая-то нагруженность, то адаптер будет держать пул открытых сессий, чтобы не устанавливать сессию и соединение на каждый запрос.
Вывод: у адаптера появилось состояние
3) Если мы хотим иметь возможность подключать разные базы — то нам надо написать несколько адаптеров, по одному на базу. И они должны предоставлять одинаковые функции.
Вывод: появился полиморфизм между адаптерами
4) Начинаем писать адаптеры для разных баз, и обнаруживаем, что у MySQL и у MariaDB очень много общего, даже установка сессии. А вот с PostrgeSQL уже меньше, но функции по созданию и разрыву сокетов и шифрования — одинаковые. Мы же не хотим код дуплицировать? В результате у разных адаптеров появляются общие функции.
Вывод: у адаптеров теперь иерархия с наследованием
Итого: как только мы затянули архитектурный паттерн (Ports and Adapters aka Hexagonal Architecture) из ООП мира, он нам отравил наш ФП проект.
В результате мы на ФП языке заимплементили ООП ручками (для иерархии адаптеров выполняются все 3 принципа ООП, и у адаптера есть состояние) вместо того, чтобы положиться на поддержку в компиляторе.
Вывод: применение старых паттернов натягивает сову ФП на глобус ООП.