Lecture 2 minutes
Nous allons parler ici de l'héritage conditionnel. Derrière ce nom barbare se cache une astuce de modularité très puissante.
La plupart des frameworks proposent des mécaniques d'override (ou fallback, ou extension, ou ...). Cela répond au besoin de pouvoir remplacer une brique de l'application par une autre. Et par "brique", on entend "classe".
Ce type d'altération peut être mis en place via différents systèmes :
- Pattern Décorateur
- Polymorphisme classique
- Polymorphisme lié au framework
- ...
Nous allons nous attarder au polymorphisme de manière générale. L'idée est simple : on étend (extend) la classe dont le comportement est à altérer, et on réécrit le code qui nous intéresse (le plus souvent le tout est accompagné d'un jeu de fichiers de configurations).
Le cadre étant posé, voici le cas à étudier :
Une image étant toujours plus claire que de longs discours, voici une représentation UML de la chose :
- RewriteObject : La classe qui doit hériter de Parent1 OU Parent2
- RewriteAdapter : La classe qui va décider de l'héritage
- Parent1 et Parent2 : Les classes dont on doit hériter de manière conditionnelle
Nous n'allons pas nous attarder sur RewriteObject, Parent1 et Parent2, qui sont des classes sans particularité.
En revanche, que contient RewriteAdapter ?
1 2 3 4 5 |
if (something()) { class RewriteAdapter extends Parent1 {} } else { class RewriteAdapter extends Parent2 {} } |
C'était aussi simple que ça.