La programmation orientée composant (POC) consiste à utiliser une approche modulaire au niveau de l'architecture d'un projet informatique, ce qui permet d'assurer au logiciel une meilleure lisibilité et une meilleure maintenance. Les développeurs, au lieu de créer un exécutable monolithique, se servent de briques réutilisables.
La POC n'est pas sans similitudes avec la POO, puisqu'elle revient à utiliser une approche objet, non pas au sein du code, mais au niveau de l'architecture générale du logiciel.
La POC est particulièrement pratique pour le travail en équipe et permet d'industrialiser la création de logiciels.
Lorsque l'on parle de composants, il s'agit de simples fichiers, contenant généralement du code compilé. Sous les systèmes de type Unix, par exemple, les composants se présentent sous la forme de fichiers portants l'extension .so (shared object). Sous les systèmes de type Microsoft Windows, il s'agit des fameuses dll (dynamic library link). On parle également de modules, de bibliothèques, ou de librairies, par abus de traduction (library étant un faux ami et signifiant bibliothèque)
Il est possible de créer des composants avec la grande majorité des langages. Toutefois, dans certains cas, notamment pour les langages interprétés ou semi-compilés il n'est pas possible de créer des composants "classiques". Par exemple, en python, les composants sont des simples fichier contenant du code (.py), tandis qu'en java, il est possible de créer des bibliothèques de classes (.jar). Ainsi, seul un programme écrit en java pourra utiliser comme composant un fichier .jar.
Un composant regroupe un certain nombre de fonctionnalités qui peuvent être appelées depuis un programme externe, ou client. Comme le composant ne contient que du code compilé, il n'est a priori pas possible de savoir de quelle manière elles sont implémentées, à moins de disposer du code source. De plus, pour pouvoir être utilisé, le composant doit fournir une interface, c'est-à-dire un ensemble de fonctions lui permettant de communiquer avec le programme client. Dans le cas où le code source n'est pas disponible, les spécifications détaillées de ces fonctions doivent être fournies avec la documentation.
Un composant est censé fournir un service bien précis. Les fonctionnalités qu'il encapsule doivent être en rapport et cohérentes entre elles. On verrait mal l'intérêt d'un composant regroupant les tâches de gestion d'impression et de compression de fichiers, par exemple.
Enfin, un composant doit être réutilisable, c’est-à-dire qu'il ne doit pas simplement servir dans le cadre du projet durant lequel il a été développé. Cet aspect n'est possible qu'à la condition qu'il possède un comportement suffisamment général. Trouver un compromis entre la spécialisation du composant pour optimiser son utilisation dans le cadre du projet actuel, et sa généralisation en vue de sa réutilisation est souvent un casse-tête lors de la phase de conception du projet.
Comme le composant n'est utilisable qu'une fois compilé, la méthode d'implémentation importe peu. Il est possible d'utiliser une approche objet ou procédurale. Il convient d'éviter une confusion courante : la POC et la POO sont des choses différentes. Utiliser la POO pour développer un composant est facultatif. En fait, l'implémentation du composant n'a aucune influence sur les programmes clients, du moment que les signatures de l'interface ne changent pas.
Le code d'un composant peut en effet être séparé en deux parties. Tout d'abord, les méthodes et données internes. Un composant peut implémenter des fonctions qu'il utilise "pour son compte personnel", et qui ne sont pas accessibles de l'exterieur. On parle de méthodes "privées". Ensuite, le composant, pour pouvoir être utilisé, doit fournir un moyen de communication avec les programmes clients. Certaines fonctions sont donc accessibles de l'exterieur, et dévolues à être appelées par ces programmes. On parle de méthodes "publiques", ou d'"interface".
Parler des différentes phases de compilation, lien à l'exécution, etc.
montrer des exemples de codes et d'instructions de compilation qui permettent d'utiliser les composants
Les avantages à utiliser une approche POC pour conduire un projet sont multiples :
Bien que l'utilisation de la POC soit réellement appréciable dans la conduite d'un projet de développement, elle n'est pas sans imposer quelques désagréments et arrachages de cheveux au chef de projet.
Tout d'abord, la POC est une méthode dont le bénéfice se voit surtout sur le long terme. En effet, lorsque l'on parle de réutilisation, de facilité de déploiement, c'est que le développement est sinon achevé, du moins bien entamé. Mais factoriser un logiciel en composants nécessite un important travail d'analyse. La rédaction des signatures des méthodes devra être particulièrement soignée, car modifier une signature nécessitera de retravailler toutes les portions de codes du projet qui font appel au composant, et l'on perdrait alors les bénéfices de l'indépendance des briques logicielles.
En un mot, si la POC industrialise le développement, la phase de conception du logiciel prendra un rôle encore plus important.
Le fait de ne pas connaître l'implémentation d'un composant (à moins d'avoir accès au source), peut également gêner certains chefs de projets qui veulent garder un contrôle total sur leur logiciel.