Tout commence par la découverte du code d'un programme utilisant Angular, et en particulier NgRx. Je me retrouve propulsé plus de 20 ans en arrière, avec une approche intégralement en callbacks, et pour s'y retrouver dans ce magma de fonctions : des noms, des noms, des noms. Une explosion de noms. Une addition ? Un nom. L'affectation à une variable ? Un nom. Cette pratique antédiluvienne de nommer tous ces petits fragments de code avait normalement disparue quand on a arrêté de faire de l'assembleur. Et pourtant, NgRx est à la mode. Et ça parce que NgRx est au pinacle de la modernité, un croisement entre Redux, la programmation réactive et Angular : en cumulant trois biens, comment peut-on être autrement qu'exceptionnel ?

Revenons sur ces noms : on parle de magasin, d'action, de réducteur, d'observable et d'effet, avec des liaisons sémantiques souvent parachutées. La lecture de la documentation est surprenante, on la croirait écrite par un ChatTouPT : la grammaire est correcte, les mots existent, des phrases font sens, et tout d'un coup, le vide, l'absence de logique, l'absence de sens... Au milieu de cette forêt je repère le mot observable, répété régulièrement par des collègues, qui me rappelle naïvement le modèle de conception observateur du GoF. J'aborde donc le sujet avec dans l'idée qu'un observable est celui qui est observé par un observateur (ou observer). Mais ça ne fonctionne pas. On pourrait dire que les effets et les réducteurs sont des sortes d'observateurs, mais un observateur est normalement notifié selon une interface qui a du sens pour la quantité de données et les changements poussés par l'observé. Ici rien de tout ça, l'observateur doit avant tout faire attention à... la gestion des erreurs d'une part, et à la notion de complétion d'autre part.

Côté GoF, la gestion des erreurs ne fait pas partie de Observateur, elle est réalisée à travers les mécanismes standards en POO, c'est-à-dire avec des exceptions. Et pour la notion de complétion, celle-ci se matérialise par la mise en place d'un gestionnaire de changement ou ChangeManager si cette notion est importante à gérer, ce qui n'est pas le cas de base de Observateur. D'autres choses font tiquer, comme le fait de créer un observable avec une simple valeur, qu'on change ensuite à la main, sans aucune notion d'extériorité. On trouve aussi dans la documentation un observable qui ne change pas, et donc qui n'a pas besoin d'être observé, vu que le patron de conception Observateur n'est là que pour ça : le changement.

Quelque chose n'allait donc pas dans la compréhension de NgRx par l'angle du patron de conception Observateur. Je reprends mes pérégrinations, je retombe sur la documentation officielle de NgRx, et tout me paraît soudainement moins confus, plus explicite, et même cohérent. Ça parle beaucoup moins de ces actions qui ne suivent pas le patron de conception Commande du GoF mais qui sont juste des encapsulations de paramètres avec un nom. Ça ne parle pas plus non plus de ces fameux réducteurs, qui dans Commande sont la partie active de l'action. Jusqu'à ce que quelqu'un me signale que ce n'était pas la documentation de NgRx mais de RxJS !

Sur cette documentation on apprend d'autres choses, comme par exemple qu'il est logique de recevoir des événements alors que la souscription n'est pas terminée, voire qu'il est normal qu'il n'y ait plus rien à observer une fois la souscription faite, tout se passant pendant la souscription. Là on est à l'opposé complet d'Observateur, où on a quasiment la garantie que rien ne va se passer pendant la souscription. En continuant un peu dans la partie glossaire, on va découvrir l'observable froid et l'observable chaud. L'observable froid, c'est celui qui crée un producteur pour chaque souscripteur au moment de la souscription. Et là nous sommes passés complètement au-delà du patron de conception Observateur, dans lequel on n'a pas besoin de notions séparées de producteur et de consommateur. Le sujet produit, l'observateur... ne consomme pas : en effet, quand quelque chose est consommé, il n'est plus disponible pour quelqu'un d'autre, et dans le patron de conception Observateur, tous les observateurs reçoivent une notification à la base identique.

Alors pourquoi introduire cette notion de consommateur, c'est étrange ! Continuons sur le glossaire RxJS, avec l'observable qui est défini comme un gabarit pour connecter un observateur en tant que consommateur à un producteur via une action souscrire, résultant en une souscription. RxJS définit donc que l'observable n'est pas observé, c'est le producteur qui l'est, parce que l'observateur n'est rien de plus qu'un consommateur. On ne trouve pas dans ce même glossaire la notion de sujet, elle n'est pas suffisamment importante, mais elle est quand même présente dans la documentation. Étant donné que le mot est directement copié depuis le patron de conception Observateur, dont RxJS se réclame en tant que... ReactiveX ? Diantre, encore un nouveau terme. Bref, étant donné que RxJS se réclame de Observateur, alors on devrait trouver une très forte similarité sous l'intitulé sujet.

RxJS présente sujet comme ceci : un sujet est un type spécial d'observable qui permet aux valeurs d'être envoyées à plusieurs observateurs. Deux remarques : dans Observateur, tous les observateurs reçoivent la même notification, néanmoins, une notification dans Observer n'est de base pas sous la forme d'une valeur, mais d'un signal. Un observable standard n'est donc définitivement par un sujet dans Observer, il n'en a pas du tout les mêmes caractéristiques. RxJS met aussi en avant la caractéristique suivante : tout sujet est un observateur ; c'est un objet possédant les méthodes de l'observateur. A ce stade, il est temps d'aller ouvrir les fenêtres, taper deux ou trois tapis, et passer un coup d'aspirateur. Cette récursivité n'a aucune existence dans le patron de conception Observateur : il n'y a aucune raison pour le sujet d'être un observateur, absolument aucune. Parce que ce patron de conception suit un des principes de bases de l'informatique : la séparation des préoccupations. Juge et partie. Créancier et endetté. Surveillant et prisonnier. Sujet et observateur.

Puisque ce mot ReactiveX est apparu au-dessus, allons voir si cette notion est différente de ce côté-ci. La présentation commence comme suit : un Sujet est une sorte de pont ou de mandataire disponible dans certaines implémentations de ReactiveX, qui agit à la fois comme observateur et comme Observable. La finalité est inversée par rapport à RxJS. Dans un cas on dit que le principe est de pouvoir être utilisé comme Sujet au sens de Observateur (sans le désigner), de l'autre on se décorrèle de Observateur et on le définit directement par un autre patron de conception, uniquement sous un enjeu technique. Et dans les deux documentations, il est très clair qu'aucun pont direct avec le patron de conception Observateur n'est écrit. En tout cas, la page Sujet côté ReactiveX est abondamment alimentée à l'aide de diagrammes, dits diagrammes de billes, parfaits pour illustrer la stratégie d'architecture tuyaux et filtres (pipes and filters), décrit dans Pattern-Oriented Software Architecture (plus connu sous le petit nom de POSA).

Du côté de notre documentaliste préféré de patrons en tout genre, oui, je parle de Martin Fowler, l'approche de ReactiveX est catégorisée comme patron de programmation, sous le nom pipeline pour les collections (Collection Pipeline), qu'il définit comme étant une spécialisation de tuyaux et filtres. Bien sûr, aucun de ces termes n'est référencé dans la documentation de ReactiveX. Au final, cette partie Observateur, mise en avant extrêmement fortement par ReactiveX et ses dérivés, ne participe pas vraiment à la compréhension de ce qu'est ReactiveX et Observable. C'est à la limite dommageable pour ceux qui connaissent bien ce patron de conception, les emmenant sur des fausses pistes logiques.

Une note humoristique pour conclure : le terme observable avait été utilisé dans InterViews de Mark A. Linton et al. Un des des co-auteurs du GoF avait travaillé sur InterViews, le GoF étant un travail postérieur. L'observable de InterViews est identique au sujet du GoF. C'est comique non ?

Petite anecdote : côté Java, depuis plus d'un quart de siècle, la classe représentant le Sujet s'appelle java.util.Observable.

Vous pouvez trouver le reste de la série sous l'article d'introduction.