Bonjour
La mouvance Reactive Programming remonte aux années 90.
On a eu dans le passé des tentatives comme Reactive C ou Reactive C++
Mais si le modèle de programmation est en soit séduisant, on constate toujours qu'il est peu utilisé par les développeurs.
Le plus souvent des frameworks viennent encapsuler le modèle et du coup les développeurs ne l'utilisent qu'au travers du framework.
Une petite recherche de reactive programming donne suffisamment de réponses pour comprendre que le concept est toujours vivant.
Mais il s'agit d'une notion théorique suffisamment large pour englober beaucoup d'approches.
Alors qu'Oblect.observe proposait d'observer les changements d'état d'un objet, NRP propose des réseaux de processus qui réagissent entre eux.
pour JavaScript cet article liste quelques approches
http://blog.getsetbro.com/js/FB-reac...reactiveX.htmld'un point de vue plus théorique, l'INRIA a pas mal travaillé sur le sujet
http://www-sop.inria.fr/mimosa/rp/ge...ion/index.htmlIl ressort de tout ça que bien que séduisant le modèle de la programmation réactive n'a pas abouti à une adhésion massive de certaines de ces approches pour amener à un consensus qui ouvre la porte à une généralisation.
Vu que EcmaScript est un langage interprété, une autre approche du développement n'est pas simple à mettre en oeuvre. il s'agit de la programmation orientée aspect POA
Dans cette approche, on se concentre sur divers aspects du produit qu'on va développer de façon séparée.
L’idée c'est qu'une même entité suivant le point de vue n'a pas besoin des mêmes méthodes et/ou données.
D'un point de vue du métier, un employé dans une application RH, n'est vraiment pas la même chose que le point de vue de l'exploitant de l'application.
Pour cela, l'AOP définit des greffons qui seront activés à certains moments dans le code décrit par les aspects. Pour y parvenir dans les langages compilés, on utilise un tissage qui va produire le code exécutable en assemblant tous les greffons.
Dans un langage interprété, il est difficile d'implémenter le tissage. Sauf si on possède un modèle de programmation réactive au niveau des procédures.
lorsqu'on écrit
1 2 3
| after () : set() {
Display.update();
} |
cela signifie après l'exécution de la méthode set exécuter Display.update.
Cette simple formulation permet de comprendre qu'avec un événement (reactive programming) qui se produit aux "points de coupe" potentiels des fonctions. On peut facilement mettre en oeuvre une programmation par aspect.
On obtient de fait du code beaucoup plus propre.
l'exemple typique est la classe métier auquel on ajoute des greffons pour la persistance, d'autres pour la supervision, etc.
Inconvénient le code qui s'exécute pour une action est dispersé dans divers greffons.
A+JYT
0 |
0 |