#POO

L’orthodoxie en vigueur dans la conception d’applications Web et de micro-services applique un schéma qui s’apparente plutôt à une approche procédurale, bien que s’appuyant sur des techniques et des languages dits orientés objets. Je vous propose une autre voie, plus orientée objet, dans laquelle les relations entre services et objets métiers sont inversés.

Il y a plusieurs années de ça, dans le cadre d’un projet de restructuration d’un programme, initialement conçu selon une approche procédurale multi-couches encore en vigueur dans les années 2000, vers une conception plus orientée objet, un des développeurs a lancé, sur le renommage des DAO en Repository, que ce ne sont que des mots qui désignent la même chose. Récemment, dans un tout autre contexte, j’ai reçu une reflexion similaire sur la dénomination de classes d’objet dont les noms étaient soit technique, soit généraliste (du genre FooService ou FooManager).

Il arrive fréquemment qu’avec l’évolution des besoins dans le temps, les objets métiers qui ont été définis auparavant nécessitent d’être étendus par l’ajout de nouvelles fonctionnalités. Selon la nature des langages de programmation, mais aussi selon les caractéristiques propres aux langages, les méthodes d’extension varient et peuvent être plus ou moins aisées à mettre en œuvre, en particulier lorsque les extensions sont fournies dans des modules (paquetages, bibliothèques, …) à part et que l’existant ne doit pas être impacté par ces ajouts (ou du moins le minimum possible).

Dans un billet précédent sur l’égalité d’identité et celle de valeurs, je vous ai parlé d’objets immutables pour lesquels l’égalité de valeur et l’égalité d’identité se confondent. J’ai souvent vu dans divers blogues sur l’immutabilité en Java l’utilisation du mot clé final. J’ai toujours trouvé son usage pour réaliser l’immutabilité comme absurde et surtout par trop contraignant. Pour moi, il ne sert à rien de qualifier les propriétés des objets comme des constantes étant donné que celles-ci doivent être encapsulées selon les principes de la programmation orienté objet. Non, l’immutabilité des objets devrait au contraire se faire au niveau du comportement et surtout des mutateurs de ces objets.

J’aime à dire que l’évolution en informatique ne connait que très peu de ruptures et ressemble à une grande spirale dans laquelle les nouvelles technologies et approches ne sont que des reprises de plus anciennes que l’on a dépoussiéré et adapté aux attentes et au temps actuel ; c’est ce qui est appelé innovation. Les micro-services, le grand buzz de l’année 2015, n’échappent pas à cette règle. (On est friand aussi de buzz en informatique). Mais qu’est-ce que les micro-services ? En fait, rien de spécial. Ce n’est ni plus ni moins que le découpage des responsabilités des applications dans des services dédiés, sur un socle HTTP, et qui communiquent entre eux par messages. Du SOA ? Du REST ? … Oui, tout ça, mais ce n’est plus à la mode, il faut parler maintenant de micro-services.

La Programmation Orienté Objet (POO pour les intimes) est de nos jours la lingua franca de la programmation dite impérative. Pourtant, fort est de constater que celle couramment usitée est loin de l’approche définie par son auteur, Alan Kay, au point que l’on peut dire qu’il existe actuellement en fait deux approches orientées objet !