"
Extensões reativas " é mais do que uma estrutura. Pelo menos porque existe uma implementação quase idêntica (ajustada para os recursos específicos do idioma e as práticas de otimização correspondentes) para cada YP popular. Yesenin afirma que "o grande é visto à distância". Nesta nota, recuarei para diferentes "distâncias" e descreverei o que vejo.
Zen primeiro
Eu vejo uma versão push do
Iterator clássico 'uma implementação GoF. Eu já
escrevi sobre isso, portanto, sem detalhes.
Uma breve recontagem para quem tem preguiça de lerO
ponto é que o
Observer é uma (quase) "imagem espelhada" da implementação clássica do Iterator. Por que "quase" - explicou em um post no link fornecido anteriormente. Nota importante: “reflexão espelhada” é uma definição matemática sem cinco minutos e pode ser
formalizada estritamente .
A essa distância, a diferença entre os sistemas push e pull é claramente visível. Após essa inspiração, cada empurrão git e puxão git causam reverência quase reverente. Você começa a vasculhar o código e a fazer perguntas sagradas sobre duplos.
Zen segundo
“Algo continua” (próximo método), “algo terminou” (método concluído), “tudo deu errado” (método de erro) - três declarações que podem descrever qualquer processo que se desenvolva ao longo do tempo. Além disso, é fácil abstrair do tempo físico, substituindo-o por uma “sequência de estados” (na qual o sistema se encontra). O Rx permite reduzir uma ampla variedade de algoritmos para uma única interface (no sentido de "concordância" do programador com outros programadores e, mais importante, com a máquina), sem impor restrições à expressividade (o número de estados possíveis) ou ao (opcional: síncrono , assíncrona ou multithread).
A conclusão mais importante se segue: um rx é um processo. E se um processo complexo consiste em n subprocessos, então ... um rx de "ordem superior", que controla a operação de n rx "primeiro pedido". Por analogia com
funções de ordem superior .
Zen terceiro
Por analogia com funções? Sim, características. A última e mais poderosa percepção é que rx é apenas a decoração de uma função - programática, não matemática: a última vive fora do tempo; uma função regular é capaz de retornar um resultado; apenas uma vez. E próximo (resultado); - Esta é uma versão "reutilizável" de retorno. Daí a conclusão mais importante: tudo o que pode ser feito com funções matemáticas (puras) e comuns de POO (incluindo
currying ,
composição e muito mais, às quais este ensaio não se dedica) pode ser feito com rx. As funções são bloqueadoras e assíncronas: rx também. Funções podem retornar funções: rx também. As funções podem ser recursivas: rx também. Os cálculos de funções podem ser armazenados em cache: também em rx.
É curioso que, nesse estágio de entendimento, você involuntariamente retorne à ... programação funcional. Não por uma questão de declaratividade, não por uma questão de imunidade - esses são todos os bônus (opcionais). No "funcional", porque é forçado a pensar em termos de funções e suas composições; e de acordo com a lei imutável “um rx é um processo”, são funções (não classes, classes abstratas, interfaces ou qualquer outra coisa) que se tornam o “ponto de partida” no design.
Eu tenho tudo.