L'aprés POO : la Programmation Orientée Composants

De nos jours tous les programmeurs savent et pratiquent intensivement la programmation orientée objet (POO). C’est une méthode de conception effectivement très mature, il est possible de mal l’utiliser (mauvais choix de granularités des objets, relations mal définies), mais armé d’une bonne analyse tout doit bien se passer.
La POO à sans doute été un pas en avant énorme (passé du C au C++ représente un soulagement assez important), les programmes sont tout de suite beaucoup mieux structurés et compréhensibles si les objets sont correctement choisis. Cependant les enseignements de POO (en général et en particulier dans mon école l'UTC) n’insistent guère sur la notion d’encapsulation.

La Programmation Orientée Composant
Un objet c'est bien, mais que diriez vous d’un objet boite noire pour lequel vous ne verriez que un port de connexion (une interface). Ce concept est appelé Programmation Orienté Composant (POC), en effet un objet muni d’une interface est appelé un composant.
Pour bien comprendre ce principe de composant il vous suffit d’imaginer que vous créez un port matériel bien défini et sur lequel vous vous êtes mis d’accord avec les utilisateurs avant toute conception du composant en elle même. Les représentations graphiques des interfaces (en analyse) rappellent d’ailleurs ce concept. Ce port permet aux utilisateurs de se connecter à votre boite noire sans en connaître le contenu.

Les avantages premiers:

• Un meilleur travail en équipe, l'ensemble des interfaces est crée au cours de l'analyse, chacun peut alors travailler sur ses composants en adressant ceux des autres membres de l'équipe. Même si l'implémentation des autres composants n'est pas fini, l'adressage est valide.
• Vous pouvez facilement ajouter des fonctionnalités à vos composants, tant que vous ne touchez pas à l’existant les autres composants pourront continuer à se brancher sur le votre.
• Tout changement d’implémentation restera transparent aux autres composants si l’interface n’est pas modifiée.
• Vous pouvez distribuer votre composant sans fournir son implémentation (distribution de composant métier que vous ne voulez divulguer), seul l’interface est visible à l’utilisateur de vos composants.

Et encore plus
En poussant ce principe ce principe plus loin, deux autres avantages apparaissent :

• La possibilité de distribuer physiquement facilement ses modules, par exemple la technologie DCOM de Microsoft permet de faire appel à des composants situés sur un réseau
• La possibilité de mettre en place de meilleures méthodologies de tests. Vous pouvez créer des Modules de tests qui viendront se brancher sur vos interfaces afin de tester les réactions de votre composant. S’ouvrent alors à vous les joies du « Unit Test » et « Test Driven Devellopement » (j’en parlerai dans un futur billet)

Pour finir, il est vrai que l’utilisation réelle de POC n’est pas triviale. Définir les interfaces qui seront implémentées avant même l’écriture des blocs métier peut paraître ardue. Je pense qu’il faut une certaine expérience de génie logiciel avant d’être capable de réaliser dès l’analyse des versions définitives d’interface. C’est cependant un travail qui doit porter ses fruits, et puis le temps passé sur l’analyse n’est jamais perdu.

Exemples
Il existe des technologies mettant en oeuvre ce principe depuis maintenant relativement longtemps, vous connaissez sans doute COM de Microsoft. Plus récemment on a aussi pu voir les UserControl du .NET et les Java Beans.
On notera par ailleurs que le C# a était conçue dés le début dans une optique de POC et pas seulement POO.