Java - le patron structurel composite

Avant de commencer, vous pouvez retrouver cet article sous la forme d’une vidéo youtube : ici

Pour mieux appréhender le patron composite, il faut analyser les différents termes qui le constituent. On retrouve les mots-clefs : composite (conteneur), feuille (leaf) et component (composant / composition).

Qu’est-ce qu’un composite ?

On dit qu’un composite est formé de plusieurs éléments, il est dit « complexe ». Par exemple, on pourrait faire le parallèle avec des matériaux composites qui peuvent être constitués d’autres composites et ou d’éléments élémentaires.

Qu’est-ce qu’une feuille ?

Précédemment, nous avons parlé d’ « éléments élémentaires » ou encore « simple ». Une feuille représente ce principe et constitue notre donnée indivisible ou terminale.

Et un component ?

Il est une représentation abstraite de tous nos composites et feuilles. C’est-à-dire que « tout est component / composant ».

Qu’avons-nous compris jusque-là ?

Nous avons compris qu’un composant est composé de composites et ou de feuilles. Un composite peut se voir comme une boîte plus ou moins grosse. Elle pourrait contenir d’autres boîtes, ainsi que des objets concrets, soit nos feuilles.

En maths, on peut représenter cette logique avec les « arbres binaires » :

La racine de cet arbre est « Dossier photos de familles ». Il représente notre dossier principal.
Les « nœuds » sont d’autres dossiers comme « 2015 », qui lui-même a pour père « Vacances ».

Quant aux trois dossiers « Vacances », « Anniversaires » et « Autres », ce sont des frères. Cela veut dire qu’ils sont au même niveau et appartiennent au dossier principal.

Les « feuilles » dont rien ne peut plus descendre, sont nos fichiers « photo1 », « photo2» etc. Les descendants (ou enfants) sont les éléments issus d’un dossier. L’ensemble représente notre arbre binaire, soit notre component.

L’utilisateur passe par les méthodes de la classe « Composante ». Il faut donc être minutieux et n’ajouter que des méthodes communes à nos composites et feuilles, au risque de ne pas respecter le principe de « Ségrégation des interfaces (ISP) ».

Le lien entre une feuille et un composite peut exister sous plusieurs formes différentes : une liste ou encore la composition. En se basant sur la représentation UML, une feuille héritera directement d’un component. Alors qu’un composite concret héritera de sa forme abstraite.

Grâce au patron composite, nous pouvons représenter une structure de données récursives. C’est-à-dire qu’il est possible de créer un lien hiérarchique entre elles.

Cela se matérialise par le fait que chaque composant d’un objet composite peut être soit un_ objet simple_ (feuille), soit un autre composite .

Le client ignore totalement la profondeur de la composition.

Les objets composites peuvent donc contenir des objets composites, qui à leur tour peuvent contenir d’autres objets composites ou feuille.

Avec cette architecture, nous respectons le principe « ouvert / fermé » car nous pouvons ajouter de nouveaux éléments sans changer le code actuel.

Voyons une application simple de ce principe :

Tout est une expression mathématique. Cette interface comprend les méthodes qui sont communes à toutes les autres classes.

Le client interagie avec les éléments de cette arborescence de la même façon via les méthodes de cette interface. Un chiffre est une « donnée terminale ». « Binaire » est un composite abstrait qui est implémenté par les composites concrets « Addition », « Soustraction » et « Multiplication ».

Dans l’exemple, nous créons deux objets « chiffres » qui auront respectivement 1 et 2 comme valeur.

La première expression prépare la création d’un composite contenant nos deux chiffres précédents. Lorsque je déclenche la méthode « getValeur() », je lance une réaction en chaîne qui me donnera le résultat de mon calcul.

En premier, j’appellerais le getValeur() d’addition puis ceux des chiffres.

Cette méthode nous permet de manipuler nos éléments de la même manière. En effet, nous n’avons pas à savoir si un élément est un composite ou une feuille.

Quand utiliser ce patron :

1. Hiérarchie de composants / forme d’une arborescence
2. Le client communique de la même manière entre les composants. Cela veut dire aussi qu’il n’a pas à connaitre les classes concrètes.

---