Software component.

Définir une brique logicielle réutilisable.

Un composant se conforme à au moins un modèle de composants (components framework).

Parce que le but des composants est d'être réutilisable, la préoccupation constante d'un modèle de composants est de limiter les dépendances du code d'un composant (avec un environnement donné, avec d'autres composants, etc.).

Ceci est généralement mis en oeuvre via un conteneur, où les composants sont déployés. Les composants ne dépendent alors plus que de ce conteneur, qui leur fournira d'éventuelles dépendances de manière standardisée (injection ou callbacks par exemple).

Ils intéragissent avec lui de manière :

  • explicite, en lui demandant par exemple de contacter un autre composant. C'est alors le conteneur seul qui connait les véritables coordonnées de ce composant (la machine où il se trouve, son type, etc.), alors que le composant n'a indiqué que des coordonnées symboliques (traduites en véritables coordonnées par le conteneur).
  • implicite, en demandant par contrat à recevoir un certain nombre de services (persistance, événements, sécurité, transactions, etc.). Le conteneur remplit alors ce contrat en s'interposant toujours entre le composant et ses clients (vérifiant les appels, démarrant des transactions, etc.) ou en appelant arbitraitrement le composant à des moments opportuns de son cycle de vie (je vais sauver ton état dans une base de données, je vais pooler ton instance, etc.)
  • Le contrat entre composant et conteneur peut être signé via une conformité du code à une API (framework), via un descripteur externe, ou les deux.
  • L'absence totale de dépendance est très difficile à assurer. La solution généralement choisie est de scinder un composant en une partie indépendante (code compilé) et une partie dépendante, facilement modifiable car sous forme de descripteurs (textuels).

Des exemples de modèles de composants sont :