Дизайн больших приложений в ФП

Дизайн больших приложений в ФП

Александр Гранин[email protected]

О себе

2

● Продолжающий хаскеллист, исследователь

● LambdaNsk - ФП-сообщество Новосибирска

● Статьи на Хабре о Haskell, о дизайне в ФП

● Haskell pet-projects

● Работаю в Kaspersky Lab (C++, C#)

О чем будем говорить

● Проектирование в ФП

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

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

3

4

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

5

6

UML

7

UML SOLIDSRP Single Responsibility PrincipleOCP Open Close PrincipleLSP Liskov Substitution PrincipleISP Interface Segregation PrincipleDIP Dependency Injection Principle

EncapsulationInheritancePolymorphismAbstractionG.R

.A.S.P

.Inversion of Control

8



.A.S.P


9



.A.S.P


10



.A.S.P


MONADSSTATE State monadIO IO monadLIST List monadID Identity monadRWS Read-Write-State monad

LazinessImmutabilityCombinatorsAbstraction

D.S.L.

High Order Functions

11



.A.S.P


MONADSSTATE State monadIO IO monadLIST List monadID Identity monadRWS Read-Write-State monad

LazinessImmutabilityCombinatorsAbstraction

D.S.L.

High Order Functions

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

12

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

13

Дизайн в ФП?

14

SOLID

SRP Single Responsibility PrincipleOCP Open Close PrincipleLSP Liskov Substitution PrincipleISP Interface Segregation PrincipleDIP Dependency Injection Principle

Inversion of Control

15

Архитектура, интерфейсы

Типы данных, модули

Код

Функциональные требования

Нефункциональные требования

Модель предметной области

Сценарии использования

Сбор и анализ требований

Реализация требований

16

ООП + UML

= ОК

17

ФП + UML

18

ФП: сбор и анализ требований

Mind Maps Use Cases (UML)

19

ФП: проектирование архитектуры

Картанеобходимости

Ассоциативнаякарта

элементов

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

20

Карта необходимости

● Крупные блоки

● Базовые требования

● Без связей

● Без структуры

21

AI

22

AI

PathFinding

Game Storage

Analysis

23

AI

PathFinding

Game Storage

Heuristics

Analysis

GameLogic

A*

24

AI

PathFinding

Game Storage

Heuristics

Prediction

Analysis

GameLogic

A* DebugView

25

PathFinding

Game Storage

Heuristics

Prediction

Analysis

GameLogic

A*L

SS

C

SSSS

GL

GL

GL

GL

GLGL

GL=Game Logic LayerV=View LayerL=LibraryC=Concept

DebugView V

AI C

GL

26

Карта элементов (ассоциативная)

● Все возможности

● Ассоциативные связи

● “Поток сознания” (!)

● Без структуры (!!)

● Легенда

Библиотеки, слои, подсистемы, концепты, данные, объекты, типы

27

PathFinding

Game Storage

Heuristics

Prediction

Analysis

GameLogic

A*L

SS

C

SSSS

GL

GL

GL

GL

GLGL


DebugView V

AI C

GL

28

PathFinding

Game Storage

Heuristics

Prediction

Analysis

GameLogic

SS

C

SSSS

A*L

GL

GL

GL

GL

GLGL


DebugView V

AI

29

Game Storage

Heuristics

PredictionAnalysis

GameLogic

A*

PathFinding Debug

View???

AI

30

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

31

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

● Упорядоченность

● Слои: IO / Pure / Business Logic

● Концепция + реализация

● Четкие ациклические связи

● Границы слоев

● Границы подсистем

● DSL, eDSL, интерпретаторы

● Функциональные идиомы

Game State Storage

Monad.STM

Концепция

Реализация

BusinessLogic Layer

Application Layer

View Layer

32

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

33

View LayerSubsystem

Business Logic LayerSubsystem

1. Контроль эффектов, связь подсистем

● FRP / Event Bus, Reactive Scenarios

Event Bus

FRP Library

ApplicationLayer

Subsystem

Interaction Logic(FRP Scenarios)

34

1. Контроль эффектов, связь подсистем


● Command eDSL (ADT), Command Interpreters

● Monad.Free, Free eDSL, Free Scenarios, Free Interpreters

2. Границы слоев / подсистем

35

CommandInterpreter

eDSL

Logic behind

Event Bus

FRP Library CommandInterpreter

eDSL

Logic behind

EventMapper

EventMapper

36


● Monad.Free, Free eDSL, Scenarios, Interpreters


37




38

3. Модель данных

● Монолитная модель - объекты описываются типами 1:1

● Комбинаторная - объекты комбинируются из частей (свойств)

Object 4 Object 5 Object 6

Object 2 Object 3

Object 1Object 1

Object 2

Object 3

Object 4

Property 1

Property 3

Property 4

Property 2

Property 5

39




40




41

● Линзы

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

Lens 2 Lens 3Lens 1

42

● Линзы


● Наивный IoC - функции высших порядков

● Monad.State Dependency Injection

5. Inversion of Control, внедрение зависимостей

43




44




45

46

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

47

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

enterprise

48

Разработчики языков,

библиотек

49


библиотек

Программисты - академики

50


библиотек


Программисты - практики

51


библиотек


Пуристы, борцы за чистоту рядов,недоброжелатели


52


библиотек



Манагеры

Большой бизнес

Пуристы, борцы за чистоту рядов,недоброжелатели

Оставшиеся вопросы

53

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

Полезные источники

54

Scott Wlaschin● How to design and code a complete program● Functional Programming Patterns● Railway Oriented Programming

Александр Гранин● Дизайн и архитектура в ФП

Спасибо за внимание!

Александр Гранин[email protected]

Вопросы?




56

Command Interpreter

Application IO

eDSL

Logic behind

Logic behind

+ Низкая связанность (Low Coupling)+ Чистота, декларация побочных эффектов+ Смена подсистемы == смена интерпретатора+ Разное поведение == разные сценарии+ Функциональное тестирование подсистем+ Мокирование == замена интерпретатора

- Дизайн и поддержка eDSL на ADT

2. Взаимодействие подсистем, контроль эффектов

57


+ Низкая связанность (Low Coupling)

+ Независимость подсистем

+ Контроль побочных эффектов

+ Разное взаимодействие == разные сценарии

+ Сценарии: Arrows / Monads / Applicatives

- Зоопарк и сложность FRP-библиотек (Haskell)

- Много возможных моделей Event Flow

- Трудно тестировать FRP-сценарии

58

● Монолитная - объекты описываются типами 1:1

+ Algebraic Data Types

+ Проста в понимании, реализации

+ Pattern Matching

+ Подходит для маленькой предметной области

- Сложность растет экспоненциально с ростом функциональности

- Монолитный код

- Зависимость кода от внутренностей модели

- Трудно адаптировать под изменяющиеся требования

3. Монолитная модель данных

4. Комбинаторная модель данных

59


+ Богатые возможности комбинаторного подхода

+ Проще адаптировать под изменяющиеся требования

+ Легко адресовать функциональность к частям модели

+ Сложность растет линейно с ростом функциональности

+ Подходит для большой и сложной предметной области

- Более сложный код обвязки (создание / изменение объектов и т.д.)

- Трудно выделить правильные комбинатоы / свойства


60

● Линзы

+ Работа со структурами любой сложности

+ Богатые возможности по трансформации и запросам к данным

+ Компактный код

- Сложность библиотек для линз (Haskell)

- Вопросы производительности




61

+ Код “сверху-вниз”, от общих функций к частным

+ IoC - привычный способ мышления

+ Подходит для небольших частей / программ

- State & Dependency Injection - Not a FP Way

- “Лобовые” решения типичных задач

- Нет места функциональным идиомам

Technology

Дизайн больших приложений в ФП