Елементи функціонального
програмування в C#
на прикладі бібліотеки Language-Ext
Автор: Юрій Науринський

1. Процес моделювання маршруту за допомогою
функціональних елементів
2. Керування функціональними елементами
3. Типові питання
4. Висновки
Зміст

Дисклеймер – яку мову програмування
ми використовуємо?
Ми використовуємо C#
Чому не F#?
Це буде зрозуміло наприкінці презентації

Guard – для валідування НЕ
бізнес-логіки
Language-Ext — бібліотека
скарбничка функціональних
елементів, про яку саме йде річ
Дисклеймер — які бібліотеки
ми використовуємо?

Специфіка домену MapService
1. Практично немає внутрішньої поведінки класів
2. Дуже багато інваріантів
3. Все залежить від зовнішніх сервісів (налаштувань, БД)
4. Контроль типів як наслідок
5. Контроль валідності стану системи

Де це все використовувати?
HERE!
Мова йде тільки про домен
Гарне питання про те,
як використовувати функціональні
елементи в інфраструктурі:
https:/
/github.com/louthy/language-ext/
discussions/1102

Процес моделювання маршруту
за допомогою функціональних елементів
● Звичайний клас
● Record
● Засилля примітивних типів
● Вічний Null
● Discriminated Union
● Опціональні значення
● Створення нового об’єкту

Звичайний клас
Немає дотримання
інваріантів
Мутабельність
Що тут потрібне,
а що ні?

Неможливо порівняти
один маршрут з іншим
Неявні винятки
Іммутабельно
А як цей клас
тоді змінювати?
Звичайний клас

Record
З переваг – компілятор
за нас написав Equals
& Compare & ToString
Елегантно (ні) вирішуємо
всі наявні проблеми одним
ключовим словом
Все ще маршрут
відповідає за інваріанти
своїх дистанції та довжини
З таким записом змінювати
рекорд за допомогою with
не можна

На жаль конструктор не генерує,
тому створення лише через init
Насправді, саме так
правильно дотримуватись
інваріантів у випадку рекордів
Record

Суттєвий мінус —
використовує
застарілий кодген
Виглядає практично так само
як і нативний рекорд, але
просто з’явився раніше
Практично всі ті самі фічі
як і в нативному.
Але є Лінзи, що зручно
Record

Недоліки:
Висновок: не є зараз актуальним, так як з’явився нативний рекорд. Буде більш
актуальним тоді, коли в ньому з’являться перевірки на Null, та буде
використовувати Source Generators.
● Допускає запис Null https:/
/github.com/louthy/language-ext/issues/1105
● Використовує застарілий кодген
Record — Language Ext

Засилля примітивних типів
Кожен раз де є дистанція
так перевіряти?
Можемо помилятися
в порядку при
створенні маршруту
Це метри, кілометри,
сантиметри, чи що?

Проблема подвійної валідації
Невже це все знову потрібно
валідувати в методі?
Щось там обчислює…

Техніка “X-ing”
Чим ці два методи відрізняються?

Відпадає питання
одиниць вимірювання
Клас обгортка
На практиці надзвичайно зручна
валідація внутрішніх значень
Засилля примітивних типів

NewType — зручне створення нових типів обгорток
NumType & FloatType — все те ж саме, але для цілих чисел,
або чисел з рухомою комою
Сигнатура:
а. NewType<NEWTYPE, A, PRED>
i. NEWTYPE — реалізуємий тип
ii. A – внутрішній тип
iii. PRED — предикат, який валідує внутрішній тип
За замовчуванням викидає виняток, якщо предикат повертає false
Є статичний метод NewOption з результатом у вигляді типу Option
Засилля примітивних типів

Ніякої подвійної валідації.
Гарантовано валідні дистанція
та тривалість
Проблема подвійної валідації

Кришталево зрозуміло, що тепер
відбувається
Техніка “X-ing”

Переваги та недоліки типів обгорток
проти засилля примітивних типів
Переваги
● Зникає проблема подвійної
валідації
● Зникає проблема “X-ing”
● Неможливо переплутати
багато однакових аргументів
місцями
Недоліки
● Необхідно постійно створювати ці
типи обгортки
● Більше навантаження на GC?
(треба вимірювати)

Вічний Null
Ідеально?
Ні, про null забули…

Зручний Fluent спосіб
валідування на null
Тільки для інфраструктурної
валідації !!!
Використовується бібліотека
Dawn.Guard
Вічний Null

Discriminated Union
Приходить бізнес-аналітик і каже:
“Дистанція маршруту тепер може бути
розділена за ознакою в місті, або за містом.
Але таке розділення не завжди потрібне.”!

А ось тут кодген вже корисний, бо
нативної підтримки типів сум (юніонів)
в C# ще (сподіваюсь) немає
Тут можливі два випадки (кейси):
● АБО загальна дистанція
● АБО розділена дистанція
Чи потрібно тут створювати
нові класи обгортки
DistanceInsideCIty & DistanceOutsideCity?
Залежить від вимог
Discriminated Union

Елегантно вирішена
проблема кількох станів
Discriminated Union

Автоматично генерується
клас конструктор юніону
Compile-time safe обробка
всіх станів
Discriminated Union

Ніби емуляція нативними
засобами мови
Але Compile-time safe обробку
прийдеться писати власноруч,
кожен раз
Discriminated Union

Недоліки:
Висновок: є зараз актуальним, бо нативних аналогів немає. Можна емулювати,
але емулювання не дає compile-time safe гарантію обробки всіх станів.
Елегантно вирішує проблему опису кількох одночасних станів.
● Допускає запис Null https:/
/github.com/louthy/language-ext/issues/1105
● Використовує застарілий кодген
Discriminated Union — Language Ext

Аксіома - Null означає
відсутність об'єкта в
застосунку,
а не в бізнес-логіці!

З C# 8 можна навіть
класи помітити як ті,
які опціонально
містять null
Але так моделювати опціональні
значення незручно
Опціональні значення

Семантична коректність та гарантія
обробки, але що таке Option?
Опціональні значення

Семантично означає опціональне
значення
Один з найвикористовуваніших типів
для моделювання домену
Не потрібно писати власноруч,
вже є в бібліотеці, разом з низкою
корисних методів
Опціональні значення

Самописний Option
з бібліотеки Uklon.Nul
Справжній Option повинен:
● Бути структурою
● Реалізовувати всі інтерфейси
порівняння та серіалізації
● Мати такі методи:
- Option<A>.Some(...)
- Option<A>.None
- Map
- Bind
Option з бібліотеки
Language-Ext
Опціональні значення

Переваги та недоліки моделювання опціональних
значень за допомогою Option чи null
Option
● Зникає проблема подвійної валідації
● Коректна семантика опціональності
● Ідеально для бізнес-логіки
● Захаращує код
Null
● Помилка часу виконання
● Семантика існування посилання
● Ідеально для інфраструктури на
кордонах застосунку (адаптери,
контролери)
● Захаращує пам’ять та час розробника

Як маючи ці два примітивні
значення створити маршрут?
Створення нового об’єкту

Оптимістичний підхід
Ціле виключення на таку незначну
дрібницю як невалідна
дистанція/тривалість?
Багато честі
Але який тип тоді потрібен, щоб
показати, що створення не вдалось?
Створення нового об’єкту

Виглядає практично як
імперативний код
Як тільки зустрічаємо перший None
● наступні кроки НЕ обробляються
● значення всього виразу стає None
Монадична обробка
Порядок обробки:
● повертає валідну дистанцію або None
● повертає валідну тривалість або None
● повертає валідний маршрут або None
Створення нового об’єкту

Але я хочу знати, яка саме
помилка при створенні
об'єкта!

Дуже зручно помилки
моделювати юніонами
Практично те саме, що й з Option, але
замість None буде CreateRouteError
Створення нового об’єкту

Зазвичай це стан
помилки
Два стани: або лівий,
або правий
Створення нового об’єкту

Але я хочу знати
ВСІ помилки при
створенні об’єкту!

Аплікативний стиль
Збираємо ВСІ помилки. Гарно працює коли всі
помилки один від одного незалежні
Створення нового об’єкту

Колекція помилок
Створення нового об’єкту

Переваги та недоліки функціонального рішення
створення нового об’єкту
Переваги
● Ніяких раптових винятків
● Даний підхід ЗМУШУЄ подумати
про обробку помилок
Недоліки
● Неясно
● Незрозуміло
● Не прийнято суспільством
● Достатньо високий поріг входження
● Через брак підтримки в мові,
потребує використання самописних
бібліотек

Висновки по створенню об’єктів
● Зовнішня простота приховує за собою внутрішню складність
● Винятки – лише для виняткових ситуацій в програмі!
● Якщо бізнес-логіка об’єкта передбачає можливість невдалого створення
об’єкта (наприклад, під час валідації) – це не виняткова ситуація!
● Можливі три різні підходи для створення об’єктів в функціональному стилі:
а. використовуючи тип Option – якщо нам важливо лише те, чи був створений об’єкт, чи ні
b. використовуючи тип Either – якщо важлива лише перша помилка при створенні об'єкта
с. використовуючи тип Validation – якщо важливо зібрати всі помилки при створенні об'єкта

Головні функції для керування
елементами
Так робити некоректно, Option не стикаються!
Якщо потрібно перетворити Option
і в результаті перетворення
отримуємо новий Option
Якщо внутрішнє значення Option
потрібно в щось перетворити
Єдиний вірний варіант отримати
внутрішнє значення (крім Match)
Всі ці функції стандартні,
також є в Either & Validation

Стандартна функція, яка
також є в Either & Validation
Оброблюємо всі
можливі стани
Головні функції для керування
елементами

Практично імперативний код!
Гуглити “do notation”
Функціонально еквівалентні
варіанти запису

● Це інша мова зі своїм специфічним синтаксисом та особливостями
● Вибір мови – це не твій персональний вибір
● Простіше вивчити нову бібліотеку ніж мову?
● C# вже дуже гарний та майже функціональний (але зрозуміло ООП
підхід перш за все)
● Вчити елементи та концепції функціонального програмування на
початку простіше в знайомому оточенні
Чому б просто не використовувати F#?

Чому саме ця бібліотека?
● Або писати самому – або брати вже готове
● На прикладі бібліотеки Uklon.Null ми побачили що буде, якщо
писати це все самому
● До того ж, є неймовірно багато речей, які можуть бути корисними, але про
них треба знати. Якщо писати самому — про них не дізнаєшся

Навіщо це взагалі потрібно?
● Дані методи дають змогу безпечно моделювати складний
домен, де багато зовнішніх залежностей
● Ці методи НЕ замінюють тести, сонар та інше, а лише
ДОПОВНЮЮТЬ!

Висновки
● Спробуйте на практиці змоделювати свою бізнес-логику за допомогою
описаних методів
● Насправді порядок моделювання не дуже важливий, до кінцевого результату ви
врешті решт прийдете використавши всі потрібні вам та описані методи
● Так в чому ж основна перевага? Ми ЗАВЖДИ знаємо, як комбінувати наші типи
декларативним способом, що автоматично робить наш код більш простим та
підтримуваним

Корисні посилання
https:/
/github.com/louthy/language-ext
https:/
/github.com/louthy/language-ext/wiki
https:/
/fsharpforfunandprofit.com
https:/
/fsharpforfunandprofit.com/posts/13-ways-of-looking-at-a-turtle
http:/
/blog.ezyang.com/2010/05/design-patterns-in-haske
https:/
/enterprisecraftsmanship.com/ps-func
https:/
/enterprisecraftsmanship.com/posts/functional-c-immutability/
https:/
/blog.ploeh.dk/
https:/
/www.youtube.com/watch?v=Nrp_LZ-XGsY

Дякую за
увагу!

Q&A