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 ce premier billet de l’année 2018, je vais m’essayer de vous présenter ce que sont les foncteurs, les foncteurs applicatifs et les monades de façon simple, sans étalage de la théorie mathématique derrière (celle des catégories) dont, de toute manière, je ne maîtrise pas. Bien que ce soient des constructions utilisées dans la programmation fonctionnelle, elles peuvent aussi être utilisées dans d’autres approches de programmation et avec d’autres langages que ceux fonctionnels. C’est pourquoi je présenterai chacun des concepts non seulement avec du code en Haskell mais aussi en Java.

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.

Il arrive dans un projet en Java de se trouver, selon le métier ou le domaine adressé, avec des classes d’objets obèses en méthodes, qu’elles soient publics ou propres aux objets de la classe. Or, sachant que l’on passe plus de temps à lire, voir à toucher du code existant qu’à en écrire de nouveaux, ceci peut vite devenir pénible. Evidemment, avec nos IDE actuels, il est facile de naviguer entre les différentes méthodes et propriétés d’une classe. Mais en général, ceci signifie que l’on sait, déjà, à peu près ce que l’on cherche ou que l’on connait a minima les responsabilités ou certaines particularités d’implémentation de la classe.

Dans certains langages de programmation, comme Java, il n’y a pas de méthodes ou d’opérateurs distincts pour différencier l’égalité d’identité et celle de valeur des objets. Si, dans un programme classique écrit dans un langage comme Java, l’égalité d’identité (de l’OID pour Object IDentifier) pourrait se faire avec l’opérateur == et celle de valeur avec la méthode equals surchargée, il n’en va plus de même dès qu’il s’agit d’objets persistés. Et là, in fine, c’est le drame : que compare t’on avec la méthode equals ? la valeur des objets ou leur identité ?

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.

Aujourd’hui, je hurle de rage ! La Loi sur le Renseignement, comme pressentie, a été adoptée à l’Assemblée Nationale aujourd’hui, le 5 mars 2015 et ceci malgré l’opposition vive de la société civile. C’est une loi liberticide qui a été voté. Elle oblige l’écoute de toutes données qui transitent dans le réseau internet et téléphonique par des boites noires, et elle autorise aux forces de police l’accès à celles-ci sans aucun contrôle judiciaire.

DragonFly BSD est le dernier rejeton de la famille des Unix BSD libres. Il est issu du désaccord de Matthew Dillon sur les choix d’architecture SMP de FreeBSD 5 en vue de supprimer le Giant Lock. Créé en 2003 à partir de FreeBSD 4.8 pour initialement proposer une autre implémentation du multi-threading (multiflot en français), plus originale, il devient l’opportunité, pour l’équipe de DragonFly BSD, d’emprunter des directions différentes, voir innovantes, de celles des autres systèmes Unix.

L’amélioration de la structuration du code d’un programme, la séparation du métier et des concepts manipulés d’avec les aspects techniques, est le Saint Graal que poursuivent sans fin les développeurs. Dans ce but, de nombreuses techniques ont fait leur apparition dont nous pouvons citer les traits ou les annotations. A côté de ceux-ci, il existe une technique élégante et uniforme que sont les slots. Mais, que sont ces derniers et en quoi peuvent ils nous aider dans notre quête ?