O que é (funcional) de programação reativa?

https://stackoverflow.com/questions/1028250

06-07-2019
|

Pergunta

Eu li o artigo da Wikipedia sobre reativa programação. Também li o pequeno artigo sobre funcional reagente programação. As descrições são bastante abstrato.

O que faz a programação reativa funcional (FRP) significa na prática?
O que faz a programação reativa (em oposição a programação não-reativo?) Consiste?

Minha formação é em linguagens imperativas / OO, então uma explicação que se refere a este paradigma seria apreciada.

Solução

Se você quiser ter uma idéia de FRP, você poderia começar com o velho Fran tutorial a partir de 1998, o que tem animado ilustrações. Para papéis, comece com reactivo funcional Animation e depois seguir em links as publicações link no meu home page eo FRP link na Haskell wiki .

Pessoalmente, eu gosto de pensar sobre o que FRP através antes de abordar como ele pode ser implementado. (Código sem uma especificação é uma resposta sem uma pergunta e, assim, "nem mesmo errado".) Então eu não descrever FRP em termos de representação / implementação como Thomas K faz em outra resposta (gráficos, nós, bordas, tiro, execução, etc). Existem muitos estilos de implementação possíveis, mas nenhuma implementação diz que FRP é .

Eu faço ressoar com a descrição simples de Laurence G que FRP é sobre "tipos de dados que representam um valor 'ao longo do tempo". Convencionais capturas imperativas de programação esses valores dinâmicos que indirectamente, através de Estado e mutações. A história completa (passado, presente e futuro) não tem primeira representação de classe. Além disso, apenas discretamente evoluindo valores podem ser (indiretamente) capturado, já que o paradigma imperativo é temporalmente discretos. Em contraste, as capturas de FRP esses valores em evolução diretamente e não tem dificuldade com continuamente evoluindo valores.

FRP também é incomum em que é concorrente, sem entrar em conflito com ninho de ratos teóricas e pragmáticas que pragas concorrência imperativo. Semanticamente, a simultaneidade de FRP é de grão fino , determinate e contínua . (Eu estou falando sobre o que significa, não implementação. Uma implementação pode ou não envolver a simultaneidade ou paralelismo.) determinacy semântica é muito importante para o raciocínio, tanto rigorosa e informal. Enquanto a simultaneidade acrescenta enorme complexidade de programação imperativa (devido a intercalação não determinístico), é fácil em FRP.

Então, o que é FRP? Você poderia ter inventado isso sozinho. Comece com estas ideias:

Dinâmico / evoluindo valores (ou seja, valores "ao longo do tempo") são valores de primeira classe em si mesmos. Você pode defini-los e combiná-los, passá-los no & fora de funções. Liguei para essas coisas "comportamentos".
Os comportamentos são construídas a partir de alguns primitivos, como constantes comportamentos e tempo (como um relógio) (estáticos), e depois com a combinação seqüencial e paralelo. n comportamentos são combinados através da aplicação de uma função n-ária (em valores estáticos), "ponto-sábio", isto é, de forma contínua ao longo do tempo.
Para conta para fenômenos discretos, têm outro tipo (família) de "eventos", cada um dos quais tem um fluxo (finito ou infinito) de ocorrências. Cada ocorrência tem um tempo e valor associado.
Para chegar com o vocabulário de composição a partir da qual todos os comportamentos e eventos pode ser construído, jogo com alguns exemplos. Mantenha desconstruindo em pedaços que são / simples mais geral.
Assim que você sabe que está em terra firme, dar todo o modelo de uma fundação de composição, utilizando a técnica de semântica denotacional, que significa apenas que (a) cada tipo tem um tipo de matemática precisa de simples correspondente & "significados", e (b) cada operador primitivo e tem um simples & significado preciso como uma função dos significados dos constituintes. Nunca, nunca misturar considerações de implementação em seu processo de exploração. Se essa descrição é jargão para você, consulte (a) denotational projeto com classe tipo morphisms , (b) push-pull funcional reactivo programação (ignorando os bits de aplicação), e (c) a denotational semântica Haskell Wikibooks página Beware que a semântica denotacional tem duas partes, de seus dois fundadores Christopher Strachey e Dana Scott:. o mais fácil e mais útil parte Strachey e a parte mais difícil e menos útil (para o projeto de software) Scott.

Se você ficar com estes princípios, eu espero que você vai ter algo mais ou menos no espírito de FRP.

Onde é que eu recebo esses princípios? Em design de software, eu sempre a mesma pergunta: "o que significa". semântica denotacional me deu um quadro preciso para esta pergunta, e um que se encaixa minha estética (ao contrário semântica operacional ou axiomáticas, ambos os quais me deixar insatisfeito). Então eu perguntei-me o que é comportamento? Logo percebi que a natureza temporal discreto de computação imperativo é uma acomodação para um estilo particular de Máquina , ao invés de uma descrição natural do próprio comportamento. O mais simples descrição precisa do comportamento que eu posso pensar é simplesmente "função do tempo (contínua)", de modo que é meu modelo. Deliciosamente, este alças modelo contínuo, a simultaneidade determinista com facilidade e graça.

Tem sido um grande desafio para implementar este modelo corretamente e com eficiência, mas isso é outra história.

Outras dicas

Na programação funcional pura, não existem efeitos colaterais. Para muitos tipos de software (por exemplo, qualquer coisa com interação do usuário) efeitos colaterais são necessários em algum nível.

Uma maneira de obter efeito colateral como o comportamento, mantendo um estilo funcional é usar programação reativa funcional. Esta é a combinação de programação funcional, e programação reactivo. (O artigo da Wikipedia é ligada ao é sobre o último.)

A idéia básica por trás da programação reativa é que existem certos tipos de dados que representam um valor "ao longo do tempo". Cálculos que envolvem esses valores-over-time muda-se terá valores que mudam com o tempo.

Por exemplo, você poderia representar as coordenadas do mouse como um par de valores integer-over-time. Vamos dizer que tinha algo como (este é pseudo-código):

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

A qualquer momento no tempo, x e y teria as coordenadas do mouse. Ao contrário da programação não-reativo, só precisamos de fazer esta tarefa uma vez, e as variáveis ??x e y vai ficar "até à data" automaticamente. É por isso que a programação reativa e trabalho de programação funcional tão bem juntos:. Programação reativa elimina a necessidade de variáveis ??mutate enquanto ainda permitindo-lhe fazer um monte de que você poderia realizar com mutações variáveis ??

Se, então, fazer alguns cálculos baseados nestes valores resultantes também será valores que mudam com o tempo. Por exemplo:

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

Neste exemplo, minX será sempre menor do que 16 a coordenada x do ponteiro do rato. Com bibliotecas reativas-aware você poderia então dizer algo como:

rectangle(minX, minY, maxX, maxY)

E uma caixa de 32x32 será desenhada ao redor do ponteiro do mouse e vai segui-lo onde quer que ele se move.

Aqui está um bom muito on funcional reativa programação .

Uma maneira fácil de se chegar a uma primeira intuição sobre o que é como é de imaginar o seu programa é uma planilha e todas as suas variáveis ??são células. Se qualquer uma das células em uma mudança de planilha, as células que se referem a essa mudança celular também. É a mesma coisa com FRP. Agora imagine que algumas das células mudar por conta própria (ou melhor, são tomadas a partir do mundo exterior.): Em uma situação GUI, a posição do rato seria um exemplo bom

Isso perde necessariamente a mais um monte. As quebras de metáfora para baixo muito rápido quando você realmente usar um sistema de FRP. Por um lado, existem geralmente tentativas para modelar os eventos discretas, bem como (por exemplo, o ratinho ser clicado). Eu só estou colocando isso aqui para lhe dar uma idéia do que é como.

Para mim, é de cerca de 2 significados diferentes de símbolo =:

Em meio x = sin(t) matemática, que x é nome diferente para sin(t). Então escrever x + y é a mesma coisa que sin(t) + y. programação reativa funcional é como a matemática, a este respeito: se você escrever x + y, é calculado com qualquer que seja o valor da t é no momento ele é usado
Em C-like idiomas (linguagens imperativas) de programação, x = sin(t) é uma atribuição: isso significa que as lojas x o valor sin(t) tomadas no momento da atribuição

OK, a partir do conhecimento de fundo e de ler a página da Wikipedia para que você apontou, parece que a programação reativa é algo como fluxo de dados de computação, mas com "estímulos" específicos externos desencadeando um conjunto de nós para o fogo e realizar seus cálculos.

Este é muito bem adaptado ao design de interface do usuário, por exemplo, em que tocar um controle de interface de usuário (por exemplo, o controle de volume em um aplicativo de reprodução de música) pode ser necessário atualizar vários itens de exibição e o volume real de saída de áudio. Quando você modifica o volume (um controle deslizante, digamos) que corresponderia ao modificar o valor associado a um nó em um grafo direcionado.

Vários nós com bordas desse nó "valor de volume" será automaticamente acionado e quaisquer cálculos e as actualizações necessárias naturalmente em cascata através da aplicação. A aplicação "reage" ao estímulo do usuário. programação reativa funcional seria apenas a aplicação desta ideia em uma linguagem funcional, ou geralmente dentro de um paradigma de programação funcional.

Para saber mais sobre "fluxo de dados de computação", procurar essas duas palavras na Wikipedia ou usando seu motor de busca favorito. A idéia geral é esta: o programa é um grafo direcionado de nós, cada um realizando algumas simples cálculo. Estes nós são conectados uns aos outros por ligações gráfico que fornecem as saídas de alguns nós para as entradas dos outros.

Quando um nó incêndios ou executa seu cálculo, os nós conectados a suas saídas têm suas entradas correspondentes "disparado" ou "marcado". Qualquer nó de ter todas as entradas desencadeada / marcado / disponíveis automaticamente incêndios. O gráfico pode ser implícito ou explícito, dependendo exatamente como programação reativa é implementado.

Nós pode ser encarado como disparar em paralelo, mas muitas vezes eles são executados em série ou com paralelismo limitada (por exemplo, pode haver alguns fios de executá-los). Um exemplo foi o famoso Manchester de fluxo de dados da máquina, que (IIRC) utilizada uma arquitetura de dados marcado para de execução do programa de nós no gráfico por meio de uma ou mais unidades de execução. Dataflow computação é muito bem adequado para situações em que computações desencadeantes de forma assíncrona, dando origem a cascatas de cálculos funciona melhor do que tentar ter a execução ser regido por um relógio (ou relógios).

importações programação Reactive essa "cascata de execução" idéia e parece pensar do programa em um fluxo de dados, como a moda, mas com a condição de que alguns dos nós são viciado ao "mundo exterior" e as cascatas de execução são acionados quando estes sensório-como a mudança nós. A execução do programa, então, olhar como algo análogo a um arco reflexo complexo. O programa pode ou não ser, basicamente, sésseis entre estímulos ou pode resolver em um estado basicamente sésseis entre estímulos.

programação "não reativa" seria a programação com uma visão muito diferente do fluxo de execução e relação com entradas externas. É provável que seja um pouco subjetivo, já que as pessoas provavelmente será tentado a dizer qualquer coisa que responde a entradas "reage" externos para eles. Mas olhando para o espírito da coisa, um programa que pesquisas de uma fila de eventos em um intervalo fixo e despacha eventos encontrado para funções (ou threads) é menos reativo (porque apenas atende a entrada do usuário em um intervalo fixo). Novamente, é o espírito da coisa aqui:. Pode-se imaginar colocando uma implementação polling com um intervalo de pesquisa rápida em um sistema em um nível muito baixo e um programa de uma forma reativa em cima dela

Depois de ler muitas páginas sobre FRP eu finalmente deparei este iluminando escrita sobre FRP, ele finalmente me fez entender o que FRP realmente é tudo.

cito abaixo Heinrich Apfelmus (autor de bananeira reativa).

O que é a essência da programação reativa funcional?

Uma resposta comum seria que “FRP é tudo sobre descrever um sistema em termos de funções que variam no tempo em vez de estado mutável”, e que certamente não seria errado. Este é o ponto de vista semântico. Mas em minha opinião, a resposta mais profunda, mais satisfação é dada pela seguinte critério puramente sintática:

A essência da programação reativa funcional é especificar o comportamento dinâmico de um valor completamente no momento da declaração.

Por exemplo, tomar o exemplo de um contador: você tem dois botões rotulado como “Up” e “Down”, que pode ser usado para aumentar ou diminuir o contador. Imperativamente, você deve primeiro especificar um valor inicial e então alterá-lo sempre que um botão é pressionado; algo como isto:
counter := 0                               -- initial value
on buttonUp   = (counter := counter + 1)   -- change it later
on buttonDown = (counter := counter - 1)
O ponto é que, no momento da declaração, apenas o valor inicial para o contador é especificada; o comportamento dinâmico de contador é implícito no resto do texto do programa. Em contraste, funcional programação reactiva especifica todo o comportamento dinâmico no momento de declaração, como este:
counter :: Behavior Int
counter = accumulate ($) 0
            (fmap (+1) eventUp
             `union` fmap (subtract 1) eventDown)
Sempre que você quiser entender a dinâmica do balcão, você só tem a olhar para a sua definição. Tudo o que pode acontecer com ele vai aparecer no lado direito. Isto é muito em contraste com a abordagem imperativo onde declarações posteriores pode mudar o comportamento dinâmico dos valores anteriormente declarados.

Assim, em meu entendimento um programa FRP é um conjunto de equações: enter descrição da imagem aqui

j é discreto: 1,2,3,4 ...

f depende t assim que este incorpora o possiblilty para modelar estímulos externos

todo o estado do programa é encapsulado em variáveis ??x_i

A biblioteca FRP cuida de progredir tempo, em outras palavras, tomando j para j+1.

Eu explico essas equações em muito mais detalhe no este vídeo .

EDIT:

Sobre 2 anos após a resposta original, recentemente, eu cheguei à conclusão de que as implementações de FRP tem um outro aspecto importante. Eles precisam (e geralmente fazem) resolver um problema prático importante:. de invalidação de cache

As equações para x_i-s descrever um gráfico de dependência. Quando algumas das mudanças x_i em j tempo, então nem todos os outros valores x_i' na necessidade j+1 de ser actualizado, por isso nem todos as dependências precisam ser recalculados porque alguns x_i' pode ser independente do x_i.

Além disso, x_i-s que fazem a mudança pode ser incrementalmente atualizado. Por exemplo, vamos considerar um f=g.map(_+1) operação mapa no Scala, onde f e g são List de Ints. corresponde aqui f para x_i(t_j) e g é x_j(t_j). Agora, se eu preceder um elemento para g então seria um desperdício para realizar a operação map para todos os elementos em g. Algumas implementações de FRP (por exemplo reflex-FRP ) destinam-se a resolver este problema. Este problema também é conhecido como computação incremental.

Em outras palavras, comportamentos (o x_i-S) em FRP pode ser pensado como cálculos ed-cache. É a tarefa do motor de FRP de forma eficiente invalidar e recalcular estas cache-s (a x_i-s) se alguns dos f_i-s fazer a mudança.

O documento Simplesmente eficiente reatividade funcional por Conal Elliott ( direta em PDF, 233 KB) é uma boa introdução . A biblioteca correspondente também funciona.

O papel é agora substituído por um outro papel, push-pull funcional programação reativa ( PDF direta , 286 KB).

Disclaimer:. A minha resposta é no contexto de rx.js - uma biblioteca 'programação reativa' para Javascript

Na programação funcional, em vez de iteração por cada item de uma coleção, você aplicar funções de ordem superior (Hofs) para a própria coleção. Assim, a idéia por trás FRP é que em vez de processamento de cada evento individual, criar um fluxo de eventos (implementado com * observável) e aplicar Hofs para que, em vez. Desta forma, você pode visualizar o sistema como pipelines de dados conectando editores para os assinantes.

As principais vantagens da utilização de um observável são:
i) abstrai estado longe do seu código, por exemplo, se quiser que o manipulador de eventos para ser demitido apenas para cada 'evento n'th, ou param de disparar após os primeiros 'n' eventos, ou começar a disparar somente após o primeiro' n 'eventos, você pode apenas usar as Hofs (filtro, takeUntil, pular, respectivamente) em vez de configuração, atualização e contadores de verificação.
ii) melhora a localidade do código - se você tem 5 manipuladores de eventos diferentes que mudam o estado de um componente, você pode mesclar suas observáveis ??e definir um único manipulador de eventos na fundiu observável em vez disso, combinando efetivamente 5 manipuladores de eventos em 1. Isto torna muito fácil de razão sobre o que eventos em todo o seu sistema pode afetar um componente, já que é todos os presentes em um único manipulador.

um observável é o dual de um Iterable.

Um Iterable é uma sequência preguiçosamente consumida - cada elemento é puxado pela iteração sempre que quer utilizar, e, portanto, a enumeração é accionado pelo consumidor.

Um observável é uma sequência preguiçosamente produzido - cada item é empurrado para o observador quando ele é adicionado à sequência, e, portanto, a enumeração é impulsionado pelo produtor.

Cara, isso é uma idéia brilhante em pânico! Por que não descobrir mais sobre isso em 1998? De qualquer forma, aqui está a minha interpretação da Fran tutorial. As sugestões são muito bem-vindos, estou pensando em começar um motor de jogo baseado nesta.

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()

Em suma:? Se cada componente pode ser tratado como um número, todo o sistema pode ser tratado como uma equação matemática, direito

O livro de Paul Hudak, A Escola Haskell de Expressão , não é apenas uma introdução bem para Haskell, mas também gasta uma quantidade razoável de tempo em FRP. Se você é um novato com FRP, eu recomendo para lhe dar uma noção de como FRP funciona.

Há também o que parece ser uma nova reescrita deste livro (lançado 2011, atualizados 2014), A Escola Haskell of Music .

De acordo com as respostas anteriores, parece que matematicamente, nós simplesmente pensar em uma ordem superior. Em vez de pensar um valor x ter tipo X , pensamos em uma função x : T ? X , onde T é o tipo de tempo, seja os números naturais, inteiros ou o continuum. Agora, quando escrever y : = x + 1 na linguagem de programação, que realmente significa a equação y ( t ) = x ( t ) + 1.

age como uma planilha como observado. Geralmente baseados em uma estrutura orientada evento.

Tal como acontece com todos os "paradigmas", é novidade é discutível.

Da minha experiência de redes de fluxo distribuídas de atores, ele pode facilmente ser vítima de um problema geral de consistência estado do outro lado da rede de nós ou seja, você acaba com um monte de oscilação e captura em loops estranhos.

Isso é difícil de evitar, alguns semântica implica laços referenciais ou de radiodifusão, e pode ser bastante caótica como a rede de atores converge (ou não) em algum estado imprevisível.

Da mesma forma, alguns estados não pode ser alcançado, apesar de ter bordas bem definidas, porque os bois estaduais globais longe da solução. 2 + 2 pode ou não chegar a ser 4, dependendo de quando as 2 da tornou-se 2, e se eles se hospedaram forma. As folhas de cálculo tem relógios síncronos e detecção de ciclo. atores distribuídos geralmente não.

Todos boa diversão:).

Eu encontrei este belo vídeo sobre o subreddit Clojure sobre FRP. É muito fácil de entender, mesmo se você não sabe Clojure.

Aqui está o vídeo: http://www.youtube.com/watch?v=nket0K1RXU4

Aqui está a fonte do vídeo refere-se no 2º semestre: https://github.com/Cicayda/yolk-examples/blob/master/src/yolk_examples/client/autocomplete.cljs

Este artigo por Andre Staltz é o melhor e mais clara explicação que eu tenho visto até agora.

Algumas citações do artigo:

programação Reactive está programando com fluxos de dados assíncronos.

Além disso, você recebe uma caixa de ferramentas de incrível de funções para combinar, criar e filtrar qualquer desses fluxos.

Aqui está um exemplo dos diagramas fantásticas que são uma parte do artigo:

Trata-se de transformações matemáticas de dados ao longo do tempo (ou tempo ignorando).

código este meio funcional pureza e programação declarativa.

erros Estado são um problema enorme no paradigma imperativo padrão. Vários pedaços de código pode mudar algum estado compartilhado em diferentes "tempos" na execução de programas. Isso é difícil de lidar.

Em FRP você descreve (como na programação declarativa) Como transforma os dados de um estado para outro e que aciona-lo. Isso permite que você ignorar tempo porque a sua função é simplesmente reagir às suas entradas e usando seus valores atuais para criar um novo. Isto significa que o estado está contido no gráfico (ou árvore) de nós de transformação e é funcionalmente puro.

Esta maciçamente reduz a complexidade e depuração de tempo.

Pense na diferença entre A = B + C em matemática e A = B + C em um programa. Em matemática que você está descrevendo uma relação que nunca vai mudar. Em um programa, sua diz que "Agora" A é B + C. Mas o próximo comando pode ser B ++, caso em que A não é igual a B + C. Em matemática ou programação declarativa Um será sempre igual a B + C não importa o momento que você pedir.

Assim, removendo as complexidades do estado compartilhado e alteração de valores ao longo do tempo. Você programa é muito mais fácil de se trabalhar.

Um EventStream é um pouco função de transformação EventStream +.

Um comportamento é uma EventStream + Alguns valor na memória.

Quando o evento dispara o valor é atualizado executando a função de transformação. O valor que isso produz é armazenado na memória comportamentos.

Os comportamentos podem ser compostas para produzir novos comportamentos que são uma transformação em N outros comportamentos. Este valor composto irá recalcular como o fogo eventos de entrada (comportamentos).

"Desde observadores são apátridas, que muitas vezes precisam de vários deles para simular uma máquina de estado como no exemplo arrasto. Nós temos que salvar o estado onde é acessível a todos os observadores envolvidos, como no caminho variável acima."

Citação de - Deprecating The Observer Pattern http://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010. pdf

A explicação curta e clara sobre aparece programação Reactive sobre Cyclejs - programação Reactive, ele usa simples e amostras visuais.

A [módulo / Componente / objeto] <> fortes é reactivo fortes significa que é totalmente responsável para gerenciar seu próprio estado por reagir a eventos externos.

Qual é a vantagem dessa abordagem? É Inversão de Controle , principalmente porque [módulo / Componente / object] é responsável por si mesmo, melhorando encapsulamento usando métodos privados contra as públicas.

É um bom ponto de partida, não uma fonte completa de knowlege. De lá você pode saltar para papéis mais complexas e profundas.

Confira Rx, extensões de Reativos para .NET. Eles apontam que com IEnumerable que são basicamente 'puxando' de um córrego. Linq consultas sobre IQueryable / IEnumerable são operações de conjunto que 'sugam' os resultados fora de um conjunto. Mas com os mesmos operadores mais IObservable você pode escrever consultas LINQ que 'reagir'.

Por exemplo, você pode escrever uma consulta Linq como (A partir de m em MyObservableSetOfMouseMovements onde m.X <100 e m.Y <100 selecionar new Point (m.X, m.Y)).

e com as extensões Rx, é isso: você tem o código UI que reage ao fluxo de entrada de movimentos do mouse e atrai sempre que estiver na caixa de 100,100 ...

FRP é uma combinação de programação funcional (paradigma construído sobre a idéia de tudo o que a programação é uma função) e paradigma de programação reativa (construída sobre a idéia de que tudo é um fluxo (observador e filosofia observável)). É suposto ser o melhor dos mundos.

Confira pós Andre Staltz na programação reativa para começar.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow