Комментарии 11
А если бы он познакомился с ФП раньше, может быть небыло бы тысяч программистов, покалеченных всякими DI, и прочими SOLID-приблудами...
Вы так пишете, как будто принципы SOLID не применимы к ФП.
Хотя у меня несколько другие агруметры(если по-честному — тут надо подготовиться), но вот это — тоже подойдёт...
1. Мы выделили весь чистый код tryAccept. И tryAccept сам по себе прекрасен. Но как тестировать tryAcceptComposition? Мы возвращаемся к тому с чего начали.
2. Если добавиться нечистого кода, например по итогу нам надо уведомлять некий третий сервис, тогда нам опять же придется или расширять tryAcceptComposition или делать еще одну обертку, что тоже не упрощает код по сравнению с ООП подходом.
3. Хотелось бы еще посмотреть как работает по итогу связка controller -> tryAcceptComposition -> tryAccept. В случае с DI контрейнером у нас есть только одно место где мы конфигурируем дерево зависимостей обращаясь к ENV ssm:// и т.д. Самый грязный код оставался в точке входа. В случае с композицией каждая *composition должна иметь доступ к конфигурации ( connectionString ) что тоже оставляет вопросы.
Частично эти вопросы затрагиваются Марком в Functional architecture — The pits of success. Еще мне понравилось как Владимир Хориков описал DDD-трилемму в Domain-driven design. Сама трилемма не отвечает три ваших вопроса, но дает некоторое направление мышления.
Я хоть и люблю функциональный стиль, но применить его получается только в ограниченных местах.
вы правильно начали писать про графы зависимостей. но вот я не увидел продолжения.
- да, зависимости — это граф (DAG), как вы и написали
- да, число нод увеличивается с глубиной (в большинстве проектов)
а вот чего я не увидел:
Марк Симан в своих статьях(1) сам же и пишет, что идеальный SOLID это набор функций, т.к. буквы S и I приводят нас в идеальном мире к "миллиону" интерфейсов одного метода, т.е. "миллиону" функций. естественно, с увеличением количества связей между ними посредством абстракций (или функций).
поэтому на вашем графе должно быть вот совсем больше стрелочек. т.е. при количестве абстракций N, число связей между ними будет M, где M > N (вполне может и 2N). При этом, если вы говорите о чистоте функций и прочих радостях, наверное, вам морально сложно будет вызывать глобальные функции отовсюду в пользу функций высшего порядка.
как следствие следствией:
DI требует описать только N абстракций, и бибилиотека сама создаст все необходимые связи в момент разрешения зависимости. в вашем примере необходимо все зависимости прописывать руками, что практически всегда будет сложнее, ведь M > N (и в этот момент откройте какой-то проект, над которым работает 30-50+ человек хотя бы год и посмотрите, насколько или во сколько именно M > N с учетом всех логгеров, конфигов и т.д.). далее это приводит к усложнению поддержки и расширению кодовой базы.
*1: https://blog.ploeh.dk/2014/03/10/solid-the-next-step-is-functional/
Ваш подход подходит только языкам с возможностью "рефлекшена". А так бы вам в composition root пришлось бы все эти зависимости ручками создавать. А так аргументы на уровне, вот в одном языке класс сразу автоматически из json можно создать, а другие более строгие этого не позволяют.
- на посте тэг .net
- отсылка на Марка Симана
Но вообще я ни в коем случае не пропагандирую никакой из подходов. Это инструменты. И нужно знать их как сильные так и слабые стороны, чтобы выбрать правильный. Вполне описанные проблемы могут быть несущественными на фоне преимуществ, или вовсе неактуальными для конкретного проекта.
п.с. По поводу ручками создавать.
Пришлось бы, но не приходится, потому что существуют инструменты.
От внедрения зависимостей к отказу от зависимостей