Рустам Шехмаметьев «Функциональные паттерны программирования на примере F#»

Переход на функциональный язык бывает тяжёл не только из-за сложности смены парадигмы, но и из-за отсутствия привычных нам паттернов проектирования. Но в функциональном программировании паттерны тоже есть. и, если вы знакомы с ними, всё становится проще, а код яснее.
В докладе мы разберём основные приёмы из арсенала функциональных разработчиков для построения типового CRUD. Также я покажу, что большинство из вас применяли эти приёмчики в некоторой степени в своём собственном коде, пусть и не в полную силу. Рекомендую просмотреть прошлый доклад по F#, чтобы освежить память: • Рустам Шехмаметьев «Ос...
Слайды: speakerdeck.co...
Ссылки:
- F# for fun and profit (fsharpforfunan...)
- Giraffe (github.com/gir...)
- Learn You a Haskell for Great Good (learnyouahaskel...)
- Computational expressions (docs.microsoft...)
Встреча: SarDotNet №6, sardotnet.time...

[@VoroninPavel]

Докладчику респект за четкость повествования.

[@voviandr]

один из самых лучших докладов по f#, что я видел. отлично !

[@monklg]

Спасибо за доклад. Не смотря что работаю в основном с ООП, доклад показался интересным и даже очень. Это смотивировало даже глянуть на проект и я нашел несколько экстеншенов реализующие данные паттерны. Как раз подумывал заюзать флюент валидацию в манере монад. В общем докладчик молодец, рассказывает задорно и примеры приземленные.

[@oxffaa]

Рустам, есть мнение, что функциональное внедрение зависимостей не самая однозначная штука. Возможно лучше делать тестируемый юнит тестами "чистый" домен без зависимостей + "грязный" домен тестируемый интеграционными тестами. Больше информации тут - blog.ploeh.dk/2017/02/02/dependency-rejection/ и ruclips.net/video/xG5qP5AWQws/видео.html

[@rustamshekhmametyev2696]

Да, внедрение зависимостей в функциональном программировании - штука неоднозначная. Здесь я показал самый простой способ DI с помощью ФП - через частичное применение, но у него есть несколько проблем. Основные из них:
1. Сложно сделать передачу каких-либо зависимостей, связанных с конфигурацией, например, connection string
2. Сложно управлять жизненным циклом зависимостей (что требуется, например, для DbContext в Entity Framework)
Есть разные способы для того, чтобы это решить в функциональном стиле, например через Reader монад.
Я согласен с вами в том, что нужно разделить домен на "чистый" и "грязный". И я считаю, что для этого лучше всего воспользоваться сочетанием ООП и ФП: "чистую" доменную логику (не взаимодействующую с внешним миром) писать в чисто функциональном стиле, а все взаимодействия с внешним миром писать в объектно-ориентированном стиле. Тогда мы сможем спокойно пользоваться частичным применением, так как все "грязные" зависимости вынесены в ООП компоненты и проблемы, описанные выше, пропадают.
Единственное, в чём вы не правы - "чистый" домен тоже может иметь свои зависимости. Главное, чтобы все они были "чистыми".

[@VoroninPavel]

​@@rustamshekhmametyev2696 Марк чрезмерный пурист. Построение запроса часто зависит от контекста, спрятанного в саму функцию. В этом вся прелесть IoC: дай мне зависимость, я попрошу ее вернуть данные так, как мне нужно. Если же получение данных вынесено в другой слой, то тут как бы или целостность (cohesion) страдает или производительность. Однако если у нас DDD, и мы работаем с агрегатами, то ок.

[@leobreydo9318]

Ну, вы бы хоть для порядка, на Скотта сослались…