Software component.
Besoin
Définir une brique logicielle réutilisable.
Analyse
Un composant se conforme à au moins un modèle de composants (components framework).
Conception
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 œuvre 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 interagissent 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.)
Notes
- 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).
Exemples
Des exemples de modèles de composants sont :