Практики и подходы, чтобы сделать большое приложение на ФЯ (Haskell)

1. Дизайн больших приложений в ФП
Александр Гранин
graninas@gmail.com

2. О себе
2
● Продолжающий хаскеллист, исследователь
● LambdaNsk - ФП-сообщество Новосибирска
● Статьи на Хабре о Haskell, о дизайне в ФП
● Haskell pet-projects
● Работаю в Kaspersky Lab (C++, C#)

3. О чем будем говорить
● Проектирование в ФП
● Элементы функционального дизайна
● Кому он в ФП нужен, этот ваш дизайн?
3

4. 4
Проектирование в ФП

5. 5

6. 6
UML

7. 7
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control

8. 8
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control

9. 9
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control

10. 10
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
MONADS
STATE State monad
IO IO monad
LIST List monad
ID Identity monad
RWS Read-Write-State monad
Laziness
Immutability
Combinators
Abstraction
D.S.L.
High Order
Functions

11. 11
UML SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Encapsulation
Inheritance
Polymorphism
AbstractionG.R.A.S.P.
Inversion of
Control
MONADS
STATE State monad
IO IO monad
LIST List monad
ID Identity monad
RWS Read-Write-State monad
Laziness
Immutability
Combinators
Abstraction
D.S.L.
High Order
Functions

12. Что такое “хороший дизайн”?
12

13. Задача дизайна - уменьшить сложность
13

14. Дизайн в ФП?
14
SOLID
SRP Single Responsibility Principle
OCP Open Close Principle
LSP Liskov Substitution Principle
ISP Interface Segregation Principle
DIP Dependency Injection Principle
Inversion of
Control

15. 15
Архитектура,
интерфейсы
Типы данных,
модули
Код
Функциональные
требования
Нефункциональные
требования
Модель предметной
области
Сценарии
использования
Сбор и анализ
требований
Реализация
требований

16. 16
ООП + UML
= ОК

17. 17
ФП + UML

18. 18
ФП: сбор и анализ требований
Mind Maps Use Cases (UML)

19. 19
ФП: проектирование архитектуры
Карта
необходимости
Ассоциативная
карта
элементов
Карта
архитектуры
подсистем

20. 20
Карта необходимости
● Крупные блоки
● Базовые требования
● Без связей
● Без структуры

21. 21
AI

22. 22
AI
Path
Finding
Game
Storage
Analysis

23. 23
AI
Path
Finding
Game
Storage
Heuristics
Analysis
Game
Logic
A*

24. 24
AI
Path
Finding
Game
Storage
Heuristics
Prediction
Analysis
Game
Logic
A* Debug
View

25. 25
Path
Finding
Game
Storage
Heuristics
Prediction
Analysis
Game
Logic
A*
L
SS
C
SS
SS
GL
GL
GL
GL
GL
GL
GL=Game Logic Layer
V=View Layer
L=Library
C=Concept
Debug
View V
AI
C
GL

26. 26
Карта элементов (ассоциативная)
● Все возможности
● Ассоциативные связи
● “Поток сознания” (!)
● Без структуры (!!)
● Легенда
Библиотеки, слои,
подсистемы, концепты,
данные, объекты, типы

27. 27
Path
Finding
Game
Storage
Heuristics
Prediction
Analysis
Game
Logic
A*
L
SS
C
SS
SS
GL
GL
GL
GL
GL
GL
GL=Game Logic Layer
V=View Layer
L=Library
C=Concept
Debug
View V
AI
C
GL

28. 28
Path
Finding
Game
Storage
Heuristics
Prediction
Analysis
Game
Logic
SS
C
SS
SS
A*
L
GL
GL
GL
GL
GL
GL
GL=Game Logic Layer
V=View Layer
L=Library
C=Concept
Debug
View V
AI

29. 29
Game
Storage
Heuristics
PredictionAnalysis
Game
Logic
A*
Path
Finding Debug
View???
AI

30. 30
Карта архитектуры подсистем

31. 31
Карта архитектуры подсистем
● Упорядоченность
● Слои: IO / Pure / Business Logic
● Концепция + реализация
● Четкие ациклические связи
● Границы слоев
● Границы подсистем
● DSL, eDSL, интерпретаторы
● Функциональные идиомы
Game State
Storage
Monad.STM
Концепция
Реализация
Business
Logic Layer
Application
Layer
View Layer

32. 32
Элементы функционального дизайна

33. 33
View Layer
Subsystem
Business
Logic Layer
Subsystem
1. Контроль эффектов, связь подсистем
● FRP / Event Bus, Reactive Scenarios
Event Bus
FRP Library
Application
Layer
Subsystem
Interaction Logic
(FRP Scenarios)

34. 34
1. Контроль эффектов, связь подсистем
● FRP / Event Bus, Reactive Scenarios

35. ● Command eDSL (ADT), Command Interpreters
● Monad.Free, Free eDSL, Free Scenarios, Free Interpreters
2. Границы слоев / подсистем
35
Command
Interpreter
eDSL
Logic behind
Event Bus
FRP Library
Command
Interpreter
eDSL
Logic behind
Event
Mapper
Event
Mapper

36. 36
● Command eDSL (ADT), Command Interpreters
● Monad.Free, Free eDSL, Scenarios, Interpreters
2. Границы слоев / подсистем

37. 37
● Command eDSL (ADT), Command Interpreters
● Monad.Free, Free eDSL, Scenarios, Interpreters
2. Границы слоев / подсистем

38. 38
3. Модель данных
● Монолитная модель - объекты описываются типами 1:1
● Комбинаторная - объекты комбинируются из частей (свойств)
Object 4 Object 5 Object 6
Object 2 Object 3
Object 1
Object 1
Object 2
Object 3
Object 4
Property 1
Property 3
Property 4
Property 2
Property 5

39. 39
3. Модель данных
● Монолитная модель - объекты описываются типами 1:1
● Комбинаторная - объекты комбинируются из частей (свойств)

40. 40
3. Модель данных
● Монолитная модель - объекты описываются типами 1:1
● Комбинаторная - объекты комбинируются из частей (свойств)

41. 41
● Линзы
4. Трансформация модели данных
Lens 2 Lens 3Lens 1

42. 42
● Линзы
4. Трансформация модели данных

43. ● Наивный IoC - функции высших порядков
● Monad.State Dependency Injection
5. Inversion of Control, внедрение зависимостей
43

44. ● Наивный IoC - функции высших порядков
● Monad.State Dependency Injection
5. Inversion of Control, внедрение зависимостей
44

45. ● Наивный IoC - функции высших порядков
● Monad.State Dependency Injection
5. Inversion of Control, внедрение зависимостей
45

46. 46
Кому он в ФП нужен, этот ваш дизайн?

47. 47
Кому он нужен, этот ваш ФП-дизайн?
enterprise

48. 48
Разработчики
языков,
библиотек

49. 49
Разработчики
языков,
библиотек
Программисты -
академики

50. 50
Разработчики
языков,
библиотек
Программисты -
академики
Программисты -
практики

51. 51
Разработчики
языков,
библиотек
Программисты -
академики
Пуристы, борцы за чистоту рядов,
недоброжелатели
Программисты -
практики

52. 52
Разработчики
языков,
библиотек
Программисты -
академики
Программисты -
практики
Манагеры
Большой
бизнес
Пуристы, борцы за чистоту рядов,
недоброжелатели

53. Оставшиеся вопросы
53
● Типы данных
● Обработка ошибок
● Работа с внешними API
● Важные структуры данных
● UI
● Базы данных
● Потоковый дизайн
● ...

54. Полезные источники
54
Scott Wlaschin
● How to design and code a complete program
● Functional Programming Patterns
● Railway Oriented Programming
Александр Гранин
● Дизайн и архитектура в ФП

55. Спасибо за внимание!
Александр Гранин
graninas@gmail.com
Вопросы?

56. ● Command eDSL (ADT), Command Interpreters
● Monad.Free, Free eDSL, Scenarios, Interpreters
1. Границы слоев / подсистем
56
Command
Interpreter
Application
IO
eDSL
Logic behind
Logic behind
+ Низкая связанность (Low Coupling)
+ Чистота, декларация побочных эффектов
+ Смена подсистемы == смена интерпретатора
+ Разное поведение == разные сценарии
+ Функциональное тестирование подсистем
+ Мокирование == замена интерпретатора
- Дизайн и поддержка eDSL на ADT

57. 2. Взаимодействие подсистем, контроль эффектов
57
● FRP / Event Bus, Reactive Scenarios
+ Низкая связанность (Low Coupling)
+ Независимость подсистем
+ Контроль побочных эффектов
+ Разное взаимодействие == разные сценарии
+ Сценарии: Arrows / Monads / Applicatives
- Зоопарк и сложность FRP-библиотек (Haskell)
- Много возможных моделей Event Flow
- Трудно тестировать FRP-сценарии

58. 58
● Монолитная - объекты описываются типами 1:1
+ Algebraic Data Types
+ Проста в понимании, реализации
+ Pattern Matching
+ Подходит для маленькой предметной области
- Сложность растет экспоненциально с ростом функциональности
- Монолитный код
- Зависимость кода от внутренностей модели
- Трудно адаптировать под изменяющиеся требования
3. Монолитная модель данных

59. 4. Комбинаторная модель данных
59
● Комбинаторная - объекты комбинируются из частей (свойств)
+ Богатые возможности комбинаторного подхода
+ Проще адаптировать под изменяющиеся требования
+ Легко адресовать функциональность к частям модели
+ Сложность растет линейно с ростом функциональности
+ Подходит для большой и сложной предметной области
- Более сложный код обвязки (создание / изменение объектов и т.д.)
- Трудно выделить правильные комбинатоы / свойства

60. 5. Трансформация модели данных
60
● Линзы
+ Работа со структурами любой сложности
+ Богатые возможности по трансформации и запросам к данным
+ Компактный код
- Сложность библиотек для линз (Haskell)
- Вопросы производительности

61. ● Наивный IoC - функции высших порядков
● Monad.State Dependency Injection
6. Inversion of Control, внедрение зависимостей
61
+ Код “сверху-вниз”, от общих функций к частным
+ IoC - привычный способ мышления
+ Подходит для небольших частей / программ
- State & Dependency Injection - Not a FP Way
- “Лобовые” решения типичных задач
- Нет места функциональным идиомам