Що таке (функціональне) реактивне програмування?

Я прочитав статтю Вікіпедії про реактивне програмування . Я також прочитав невелику статтю про функціональне реактивне програмування . Описи досить абстрактні.

1. Що означає функціональне реактивне програмування (FRP) на практиці?
2. З чого складається реактивне програмування (на відміну від нереактивного програмування?)?

Моя інформація складається з імперативних мов / OO, тому пояснення, яке стосується цієї парадигми, було б вдячно.

Якщо ви хочете відчути FRP, ви можете почати зі старого підручника з Фран з 1998 року, який містить анімовані ілюстрації. Для паперів почніть з функціональної реактивної анімації, а потім перейдіть за посиланнями на посилання публікацій на моїй домашній сторінці та посиланням FRP на вікі Haskell .

Особисто мені подобається подумати над тим, що означає FRP, перш ніж звертатися до того, як це може бути реалізовано. (Код без специфікації - це відповідь без запитання, і, отже, «навіть не помиляється».) Тому я не описую FRP в умовах представлення / реалізації, як це робить Thomas K в іншій відповіді (графіки, вузли, ребра, стрільба, виконання, тощо). Є багато можливих стилів реалізації, але не реалізація не говорить , що FRP є .

Я резоную з простим описом Лоранса Г, що FRP - це "типи даних, які представляють значення" з часом ". Звичайне імперативне програмування фіксує ці динамічні значення лише опосередковано, через стан та мутації. Повна історія (минула, теперішня, майбутня) не має представлення першого класу. Більше того, можна (побічно) захоплювати лише дискретно розвиваються значення, оскільки імперативна парадигма тимчасово дискретна. На відміну від цього, FRP фіксує ці зміни, що змінюються, безпосередньо і не має труднощів з постійно змінюються значеннями.

FRP також незвичний тим, що він є одночасною, не стикаючись з теоретичним і прагматичним гніздом щурів, що наносить імперативну сукупність. Семантично паралельність FRP є дрібнозернистою , визначеною та безперервною . (Я говорю про значення, а не про імплементацію. Впровадження може включати паралелізм чи паралелізм.) Семантична рішучість є дуже важливою для міркувань, як суворих, так і неформальних. У той час як паралельність додає величезної складності імперативному програмуванню (через недетерміновану переплетення), це є без зусиль у FRP.

Отже, що таке FRP? Ви могли це самі придумати. Почніть з цих ідей:

• Динамічні / що розвиваються значення (тобто значення "з часом") самі по собі є першокласними значеннями. Ви можете їх визначити та комбінувати, передати їх у функції та вийти з них. Я назвав ці речі "поведінкою".

• Поведінки будуються з декількох примітивів, таких як постійні (статичні) поведінки та час (як годинник), а потім із послідовним та паралельним поєднанням. n поведінка поєднується за допомогою застосування n-арної функції (на статичні значення), "точково", тобто постійно в часі.

• Для обліку дискретних явищ є інший тип (сімейство) "подій", кожен з яких має потік (скінченний або нескінченний) подій. Кожне виникнення має пов'язаний час та значення.

• Щоб придумати композиційну лексику, з якої можна побудувати всі поведінки та події, пограйте з деякими прикладами. Продовжуйте деконструювати деталі, які є більш загальними / простими.

• Так що ви знаєте, що ви перебуваєте на твердій основі, дайте всій моделі композиційну основу, використовуючи техніку денотаційної семантики, що просто означає, що (а) кожен тип має відповідний простий і точний математичний тип "смислів", і ( б) кожен примітив і оператор має просте і точне значення як функцію значень складових. Ніколи, ніколи не змішуйте міркування щодо впровадження у процесі дослідження. Якщо цей опис для вас химерний, зверніться до: (а) Денотаційного дизайну з типом морфізмів класів , (б) функціонального реактивного програмування "Push-pull" (ігнорування бітів реалізації) та (c) сторінки вікі-книг " Денотаційна семантика Haskell".. Будьте уважні, що денотаційна семантика має дві частини, від двох її засновників Крістофера Страчі та Дани Скотта: простіша і корисніша частина Страчі та більш тверда і менш корисна (для розробки програмного забезпечення) частина Скотта.

Якщо ви будете дотримуватися цих принципів, я думаю, ви отримаєте щось більш-менш у дусі FRP.

Звідки я взяв ці принципи? У розробці програмного забезпечення я завжди задаю одне і те ж питання: "що це означає?". Денотаційна семантика дала мені точну основу для цього питання, і та, яка відповідає моїй естетиці (на відміну від оперативної чи аксіоматичної семантики, обидві не залишають мене незадоволеними). Тож я запитав себе, що таке поведінка? Я незабаром зрозумів, що тимчасово дискретний характер імперативних обчислень - це пристосування до певного стилю машини , а не природний опис самої поведінки. Найпростіший точний опис поведінки, про який я можу придумати, - це просто "функція (безперервного) часу", тож це моя модель. Ця модель чудово справляється з безперервною, детермінованою одночасністю з легкістю та витонченістю.

Впровадити цю модель правильно та ефективно було вже досить складно, але це вже інша історія.

У чистому функціональному програмуванні немає побічних ефектів. Для багатьох типів програмного забезпечення (наприклад, все, що стосується взаємодії з користувачем) необхідні побічні ефекти на якомусь рівні.

Один із способів отримати такі побічні ефекти, як поведінка, зберігаючи функціональний стиль, - це використовувати функціональне реактивне програмування. Це поєднання функціонального програмування та реактивного програмування. (Стаття у Вікіпедії, з якою ви пов’язані, стосується останньої.)

Основна ідея реактивного програмування полягає в тому, що існують певні типи даних, які представляють значення "з часом". Обчислення, що включають ці значення, що змінюються за часом, самі матимуть значення, які змінюються з часом.

Наприклад, ви можете представити координати миші у вигляді пари цілих чисел за часом. Скажімо, у нас було щось на кшталт (це псевдо-код):

x = <mouse-x>;
y = <mouse-y>;

У будь-який момент часу x і y мали б координати миші. На відміну від нереактивного програмування, нам потрібно зробити це завдання лише один раз, і змінні x і y залишаться "оновленими" автоматично. Ось чому реактивне програмування та функціональне програмування так добре працюють разом: реактивне програмування позбавляє необхідності мутувати змінні, одночасно дозволяючи робити багато того, що ви могли б досягти за допомогою змінних мутацій.

Якщо ми потім зробимо деякі обчислення на основі цього, отримані значення також будуть значеннями, які змінюються з часом. Наприклад:

minX = x - 16;
minY = y - 16;
maxX = x + 16;
maxY = y + 16;

У цьому прикладі minXзавжди буде на 16 менше, ніж координата x вказівника миші. З бібліотеками, що знають про реактивність, ви можете сказати щось на кшталт:

rectangle(minX, minY, maxX, maxY)

А навколо вказівника миші буде намальовано вікно розміром 32х32 і буде відстежувати його, куди він рухається.

Ось досить хороший документ про функціональне реактивне програмування .

Простий спосіб досягти першої інтуїції щодо того, що це таке - уявити свою програму - це електронна таблиця, і всі ваші змінні є клітинками. Якщо будь-яка з комірок електронної таблиці зміниться, будь-які комірки, які посилаються на цю клітинку, також змінюються. Так само і з FRP. Тепер уявіть, що деякі клітини змінюються самостійно (вірніше, взяті із зовнішнього світу): у ситуації з графічним інтерфейсом позиція миші може бути хорошим прикладом.

Це обов'язково пропускає досить багато. Метафора руйнується досить швидко, коли ви фактично використовуєте систему FRP. Для одного, як правило, також намагаються моделювати дискретні події (наприклад, клацання миші). Я лише ставлю це сюди, щоб дати вам уявлення, що це таке.

Для мене це приблизно два різних значення символу =:

1. В математиці x = sin(t)кошти, що xце інша назва для sin(t). Отже, писати x + y- це те саме, що і sin(t) + y. У цьому відношенні функціональне реактивне програмування схоже на математику: якщо ви пишете x + y, воно обчислюється залежно від того, яке значення tмає в той момент, коли воно використовується.
2. У C-подібних мовах програмування (імперативні мови) x = sin(t)є призначенням: це означає, що xзберігає значення, sin(t) взяті на момент виконання завдання.

Гаразд, з фонових знань та з читання сторінки Вікіпедії, на яку ви вказали, виявляється, що реактивне програмування - це щось на зразок обчислень потоку даних, але зі специфічними зовнішніми "стимулами", що викликають набір вузлів для запуску та проведення їх обчислень.

Це дуже добре підходить для дизайну інтерфейсу, наприклад, коли для торкання керування користувальницьким інтерфейсом (скажімо, регулювання гучності програми для відтворення музики) може знадобитися оновлення різних елементів відображення та фактичного обсягу аудіовиходу. Коли ви змінюєте гучність (слайдер, скажімо), це відповідало б зміні значення, пов'язаного з вузлом у спрямованому графіку.

Різні вузли, що мають краї цього вузла "значення гучності", автоматично запускаються, і всі необхідні обчислення та оновлення, природно, пульсують через додаток. Додаток "реагує" на стимул користувача. Функціональне реактивне програмування - це просто реалізація цієї ідеї на функціональній мові, або взагалі в рамках парадигми функціонального програмування.

Щоб отримати докладнішу інформацію про "обчислення даних", знайдіть ці два слова у Вікіпедії або скористайтеся улюбленою пошуковою системою. Загальна ідея така: програма - це спрямований графік вузлів, кожен з яких виконує прості обчислення. Ці вузли з'єднані між собою графськими посиланнями, які забезпечують виходи одних вузлів на входи інших.

Коли вузол спрацьовує або виконує його обчислення, вузли, підключені до його виходів, мають відповідні входи "спрацьовані" або "позначені". Будь-який вузол, у якого всі входи спрацьовані / позначені / доступні, автоматично спрацьовує. Графік може бути неявним або явним залежно від того, як саме реалізується реактивне програмування.

Вузли можна розглядати як стрілянину паралельно, але часто вони виконуються послідовно або з обмеженим паралелізмом (наприклад, їх виконання може бути декількома потоками). Відомий приклад - Манчестерська машина передачі даних , яка (IIRC) використовувала марковану архітектуру даних для планування виконання вузлів у графіку через один або декілька одиниць виконання. Обчислення потоків даних досить добре підходить для ситуацій, коли запускання обчислень асинхронно спричиняє каскади обчислень, працює краще, ніж намагання виконання керувати годинником (або тактовими частотами).

Реактивне програмування імпортує цю ідею "каскаду виконання" і, здається, мислить програму подібним чином, але за умови, що деякі вузли підключені до "зовнішнього світу" і каскади виконання спрацьовують, коли ці сенсорні -подібні вузли змінюються. Потім виконання програми виглядатиме як щось аналогічне складній рефлекторній дузі. Програма може або не бути в основному силою між подразниками, або може перетворитися в стан, що знаходиться в основному, між подразниками.

"нереактивне" програмування було б програмуванням з дуже різним поглядом на потік виконання та відношення до зовнішніх входів. Це може бути дещо суб'єктивно, оскільки люди, ймовірно, будуть спокушатися сказати все, що реагує на зовнішні входи, "реагує" на них. Але, дивлячись на дух речі, програма, яка опитує чергу подій з фіксованим інтервалом і розсилає будь-які події, виявлені для функцій (або потоків), є менш реактивною (тому що вона відвідує лише введення користувачем через фіксований інтервал). Знову ж таки, тут суть справи: можна уявити, як реалізація опитування з швидким інтервалом опитування в систему на дуже низькому рівні та програмувати реактивним способом поверх неї.

Прочитавши багато сторінок про FRP, я нарешті натрапив на цю освічуючу письмову інформацію про FRP, вона нарешті дала мені зрозуміти, що насправді має FRP.

Я цитую нижче Генріха Апфельмуса (автора реактивних бананів).

У чому суть функціонального реактивного програмування?

Поширеною відповіддю було б те, що "FRP - це все, що стосується опису системи з точки зору функцій, що змінюються за часом, а не в зміненому стані", і це, звичайно, не буде помилковим. Це семантична точка зору. Але, на мою думку, більш глибоку, задовольняючу відповідь дає наступний суто синтаксичний критерій:

Суть функціонального реактивного програмування полягає у конкретизації динамічної поведінки значення на момент декларування.

Наприклад, візьмемо приклад лічильника: у вас є дві кнопки з написом "Вгору" та "Вниз", які можна використовувати для збільшення чи зменшення лічильника. В обов’язковому порядку слід спочатку вказати початкове значення, а потім змінити його кожного разу, коли натискається кнопка; щось на зразок цього:

counter := 0                               -- initial value
on buttonUp   = (counter := counter + 1)   -- change it later
on buttonDown = (counter := counter - 1)

Справа в тому, що під час декларації вказується лише початкове значення лічильника; динамічна поведінка лічильника мається на увазі в решті тексту програми. На відміну від цього, функціональне реактивне програмування визначає всю динамічну поведінку на момент декларування, наприклад:

counter :: Behavior Int
counter = accumulate ($) 0
            (fmap (+1) eventUp
             `union` fmap (subtract 1) eventDown)

Щоразу, коли ви хочете зрозуміти динаміку лічильника, вам потрібно лише подивитися на його визначення. Все, що може з ним трапитися, з’явиться праворуч. Це дуже на відміну від імперативного підходу, коли наступні декларації можуть змінити динамічну поведінку раніше оголошених значень.

Отже, на моє розуміння програма FRP - це набір рівнянь:

j дискретний: 1,2,3,4 ...

fЦе залежить від tтого, що це включає можливість моделювання зовнішніх подразників

весь стан програми інкапсульований змінними x_i

Бібліотека FRP піклується про те, щоб прогресувати час, іншими словами, взяти jна себе j+1.

Я пояснюю ці рівняння набагато детальніше у цьому відео.

Редагувати:

Приблизно через 2 роки після первинної відповіді нещодавно я дійшов висновку, що впровадження FRP має ще один важливий аспект. Їм потрібно (і зазвичай це робити) вирішити важливу практичну проблему: недійсність кешу .

Рівняння для x_i-s описують графік залежності. Якщо деякі x_iзміни відбуваються в той час, jто не всі інші x_i'значення, що j+1потребують оновлення, потребують оновлення, тому не всі залежності потрібно переробляти, оскільки деякі x_i'можуть бути незалежними x_i.

Крім того, x_iзміни, які можна змінити, можна поступово оновлювати. Для прикладу розглянемо операцію по карті f=g.map(_+1)в Scala, де fі gзнаходяться Listв Ints. Тут fвідповідає x_i(t_j)і gє x_j(t_j). Тепер, якщо я додати елемент до gцього, тоді було б марно проводити mapоперацію для всіх елементів в g. Деякі реалізації FRP (наприклад, reflex-frp ) мають на меті вирішити цю проблему. Ця проблема також відома як додаткові обчислення.

Іншими словами, поведінку ( x_i-ів) у FRP можна розглядати як кешовані обчислення. Завдання двигуна FRP - це ефективно скасувати та перерахувати ці кеші (і x_i), якщо деякі з них f_iзмінюються.

Стаття Просто ефективна функціональна реактивність від Conal Elliott ( прямий PDF , 233 KB) є досить хорошим вступом. Відповідна бібліотека також працює.

Тепер документ замінений іншим папером, функціональним реактивним програмуванням Push-pull ( прямий PDF , 286 КБ).

Відмова: моя відповідь в контексті rx.js - бібліотеки "реактивного програмування" для Javascript.

У функціональному програмуванні замість повторення кожного елемента колекції ви застосовуєте функції вищого порядку (HoFs) до самої колекції. Отже, ідея FRP полягає в тому, щоб замість обробки кожної окремої події створити потік подій (реалізований із спостережуваним *) і застосувати до цього HoF. Таким чином ви зможете візуалізувати систему як трубопроводи даних, що з'єднують видавців з передплатниками.

Основними перевагами використання спостережуваного є:
i) він абстрагує від свого коду стан, наприклад, якщо ви хочете, щоб обробник події був звільнений лише для кожної 'n' події, або припинив стріляти після перших 'n' подій, або почати запускати лише після перших подій "n", ви можете просто використовувати HoFs (фільтр, takeUntil, пропустити відповідно) замість встановлення, оновлення та перевірки лічильників.
ii) це покращує локальність коду - якщо у вас є 5 різних обробників подій, що змінюють стан компонента, ви можете об'єднати їхні спостережувані та визначити один обробник подій на об'єднаному спостерігається замість цього, ефективно поєднуючи 5 обробників подій у 1. Це робить його дуже легко міркувати про те, які події у всій вашій системі можуть впливати на компонент, оскільки всі вони присутні в одному обробнику.

• Спостережуване - це дуал Ітерабельного.

Ітерабельна - це ліниво споживана послідовність - кожен елемент витягується ітератором всякий раз, коли він хоче його використати, а значить, перерахування визначається споживачем.

Спостережувана - це ліниво створена послідовність - кожен елемент висувається спостерігачеві кожного разу, коли він додається до послідовності, а значить, перерахування визначається виробником.

Чувак, це чудова геніальна ідея! Чому я не дізнався про це ще в 1998 році? У всякому разі, ось моє тлумачення підручника Фран . Пропозиції найкраще вітаю, я думаю про те, щоб запустити ігровий движок на основі цього.

import pygame
from pygame.surface import Surface
from pygame.sprite import Sprite, Group
from pygame.locals import *
from time import time as epoch_delta
from math import sin, pi
from copy import copy

pygame.init()
screen = pygame.display.set_mode((600,400))
pygame.display.set_caption('Functional Reactive System Demo')

class Time:
    def __float__(self):
        return epoch_delta()
time = Time()

class Function:
    def __init__(self, var, func, phase = 0., scale = 1., offset = 0.):
        self.var = var
        self.func = func
        self.phase = phase
        self.scale = scale
        self.offset = offset
    def copy(self):
        return copy(self)
    def __float__(self):
        return self.func(float(self.var) + float(self.phase)) * float(self.scale) + float(self.offset)
    def __int__(self):
        return int(float(self))
    def __add__(self, n):
        result = self.copy()
        result.offset += n
        return result
    def __mul__(self, n):
        result = self.copy()
        result.scale += n
        return result
    def __inv__(self):
        result = self.copy()
        result.scale *= -1.
        return result
    def __abs__(self):
        return Function(self, abs)

def FuncTime(func, phase = 0., scale = 1., offset = 0.):
    global time
    return Function(time, func, phase, scale, offset)

def SinTime(phase = 0., scale = 1., offset = 0.):
    return FuncTime(sin, phase, scale, offset)
sin_time = SinTime()

def CosTime(phase = 0., scale = 1., offset = 0.):
    phase += pi / 2.
    return SinTime(phase, scale, offset)
cos_time = CosTime()

class Circle:
    def __init__(self, x, y, radius):
        self.x = x
        self.y = y
        self.radius = radius
    @property
    def size(self):
        return [self.radius * 2] * 2
circle = Circle(
        x = cos_time * 200 + 250,
        y = abs(sin_time) * 200 + 50,
        radius = 50)

class CircleView(Sprite):
    def __init__(self, model, color = (255, 0, 0)):
        Sprite.__init__(self)
        self.color = color
        self.model = model
        self.image = Surface([model.radius * 2] * 2).convert_alpha()
        self.rect = self.image.get_rect()
        pygame.draw.ellipse(self.image, self.color, self.rect)
    def update(self):
        self.rect[:] = int(self.model.x), int(self.model.y), self.model.radius * 2, self.model.radius * 2
circle_view = CircleView(circle)

sprites = Group(circle_view)
running = True
while running:
    for event in pygame.event.get():
        if event.type == QUIT:
            running = False
        if event.type == KEYDOWN and event.key == K_ESCAPE:
            running = False
    screen.fill((0, 0, 0))
    sprites.update()
    sprites.draw(screen)
    pygame.display.flip()
pygame.quit()

Коротше кажучи: Якщо до кожного компонента можна ставитися як до числа, то до всієї системи можна трактуватись як математичне рівняння, правда?

Книга Пола Худака - Школа експресії Хаскелла - це не лише прекрасне вступ до Хаскелл, але й витрачає досить багато часу на FRP. Якщо ви початківець з FRP, я настійно рекомендую це, щоб ви зрозуміли, як працює FRP.

Існує також те, що схоже на нове переписування цієї книги (вийшла 2011 р., Оновлено 2014 р.), Школа музики Haskell .

Згідно з попередніми відповідями, здається, що математично ми просто думаємо у вищому порядку. Замість того, щоб думати значення x, що має тип X , ми думаємо про функцію x : T → X , де T - тип часу, будь то натуральні числа, цілі числа чи континуум. Тепер, коли ми пишемо y : = x + 1 мовою програмування, ми фактично маємо на увазі рівняння y ( t ) = x ( t ) + 1.

Діє як електронна таблиця, як зазначалося. Зазвичай на основі подій, що керуються подіями.

Як і у всіх "парадигмах", новизна є дискусійною.

З мого досвіду розподілених потокових мереж дійових осіб, це може легко стати жертвою загальної проблеми узгодженості стану по всій мережі вузлів, тобто у вас виникає багато коливань і захоплення дивних циклів.

Цього важко уникнути, оскільки деяка семантика передбачає референтні цикли чи мовлення, і може бути досить хаотично, оскільки мережа акторів сходить (чи ні) на якомусь непередбачуваному стані.

Аналогічно, деякі стани можуть бути досягнуті, незважаючи на чітко визначені краї, оскільки глобальна держава відхиляється від рішення. 2 + 2 можуть бути, а можуть і не стати 4, залежно від того, коли двом стало 2, і чи залишилися вони такими. Електронні таблиці мають синхронні годинники та петлю виявлення. Розподілених акторів зазвичай немає.

Все добре весело :).

Я знайшов це приємне відео на Clojure subreddit про FRP. Це досить легко зрозуміти, навіть якщо ти не знаєш Clojure.

Ось відео: http://www.youtube.com/watch?v=nket0K1RXU4

Ось джерело, на яке посилається відео у другому півріччі: https://github.com/Cicayda/yolk-examples/blob/master/src/yolk_examples/client/autocomplete.cljs

Ця стаття Андре Стальца - найкраще та найяскравіше пояснення, яке я бачив досі.

Деякі цитати зі статті:

Реактивне програмування - це програмування з асинхронними потоками даних.

Крім цього, вам надається дивовижна панель інструментів для комбінування, створення та фільтрації будь-якого з цих потоків.

Ось приклад фантастичних діаграм, які є частиною статті:

Йдеться про перетворення математичних даних з часом (або ігнорування часу).

У коді це означає функціональну чистоту та декларативне програмування.

Державні помилки - це величезна проблема в стандартній імперативній парадигмі. Різні біти коду можуть змінювати деякий загальний стан у різні "часи" виконання програм. З цим важко впоратися.

У FRP ви описуєте (як у декларативному програмуванні), як дані перетворюються з одного стану в інший і що це викликає. Це дозволяє ігнорувати час, оскільки ваша функція просто реагує на свої входи та використовує їх поточні значення для створення нового. Це означає, що стан міститься в графіку (або дереві) вузлів перетворення і є функціонально чистим.

Це масово зменшує складність та час налагодження.

Подумайте про різницю між A = B + C у математиці та A = B + C у програмі. У математиці ви описуєте відносини, які ніколи не зміниться. У програмі написано, що "прямо зараз" A є B + C. Але наступною командою може бути B ++, у цьому випадку A не дорівнює B + C. У математичному чи декларативному програмуванні A завжди буде дорівнює B + C, незалежно від того, в який момент часу ви запитуєте.

Отже, усуваючи складності стану, що поділяються, та змінюючи значення з часом. Ви програмуєте набагато простіше міркувати.

EventStream - це EventStream + деяка функція перетворення.

Поведінка - це EventStream + деяке значення в пам'яті.

Коли запускається подія, значення оновлюється за допомогою запуску функції перетворення. Значення, яке це виробляє, зберігається в пам'яті поведінки.

Поведінки можуть бути складені для створення нових форм поведінки, які є перетворенням на N інших поведінок. Це складене значення буде перераховано як вхідні події (поведінки) пожежі.

"Оскільки спостерігачі без громадянства, нам часто потрібні декілька з них, щоб імітувати стан машини, як у прикладі перетягування. Нам потрібно зберегти стан, у якому воно доступне для всіх залучених спостерігачів, наприклад, у шляху змінної вище".

Цитата від - Позбавлення шаблону спостерігача http://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010.pdf

Коротке і чітке пояснення щодо реактивного програмування з'являється на Cyclejs - Реактивне програмування , воно використовує прості та наочні зразки.

[Модуль / Компонент / об’єкт] є реактивним, це означає, що він повністю відповідає за управління власним станом, реагуючи на зовнішні події.

Яка користь від такого підходу? це є інверсія управління , головним чином тому, що [модуль / компонент / об’єкт] відповідає за себе, покращуючи інкапсуляцію, використовуючи приватні методи проти публічних.

Це хороший стартовий момент, а не повне джерело знань. Звідти ви можете перейти до більш складних і глибоких паперів.

Ознайомтеся з Rx, Реактивними розширеннями для .NET. Вони зазначають, що з IEnumerable ви в основному 'тягнете' з потоку. Запити Linq над IQueryable / IEnumerable - це задані операції, які 'висмоктують' результати з набору. Але з тими ж операторами через IObservable ви можете писати запити Linq, які "реагують".

Наприклад, ви можете написати запит Linq на зразок (від m в MyObservableSetOfMouseMovements, де mX <100 і mY <100 виберіть нову точку (mX, mY)).

і з розширеннями Rx, це все: у вас є код інтерфейсу, який реагує на вхідний потік рухів миші та малює щоразу, коли ви знаходитесь у вікні 100 100 ...

FRP - це поєднання функціонального програмування (парадигма програмування, побудована на ідеї всього - це функція), і парадигма реактивного програмування (побудована на ідеї, що все є потоком (філософія спостерігача та спостережуваного)). Це, мабуть, найкраще зі світу.

Перегляньте пост Андре Стальца про реактивне програмування для початку.