L’héritage est un principe propre au paradigme de programmation dit “Orienté Objet”, il désigne le processus par lequel une classe va obtenir d’une autre classe tous ses attributs et ses méthodes. On dit donc qu’elle hérite de cette classe. Deux sortes d’héritages existent : simple et multiple. L’héritage simple désigne le procédé par lequel une classe va hériter d’une unique autre classe. A contrario, l’héritage multiple désigne l’héritage de plusieurs classes par une classe fille. Cette dernière aura donc toutes les propriétés (méthodes et attributs) de ces classes.
Qu’est-ce qu’un rôle ?
Un rôle englobe une partie du comportement ou un état qui peut être partagée entre les classes. C’est quelque chose que les classes vont faire. Il est important de comprendre que les rôles ne sont pas des classes. Vous ne pouvez pas hériter d’un rôle, et un rôle peut pas être instancié. On dit parfois que les rôles sont consommés, soit par des classes ou d’autres rôles. Au lieu de cela, un rôle est composé dans une classe. En termes pratiques, cela signifie que toutes les méthodes, les modificateurs de méthode et les attributs définis dans un rôle sont ajoutés directement (on dit parfois “aplati en”) la classe qui consomme le rôle. Ces attributs et méthodes apparaissent alors comme si elles étaient définies dans la classe elle-même. Une sous-classe de la classe héritera de consommer toutes ces méthodes et attributs.
Alors, qui gagne ?
Hé bien, Curtis a souligné le fait que lorsque l’on code une grosse application, on multiplie le nombre de classes. S’en suit alors une foule d’héritage qui ne fait que rendre le code plus compliqué pour la prochaine personne qui le lira, car il devra remonter tout l’arbre des héritages pour comprendre l’ensemble des codes. Alors que si la même grosse application avait été créée sur la base de quelques rôles que les classes auraient appliqué par la suite, le développeur suivant n’aura qu’à lire l’implémentation de ces rôles avant de lire les classes, et ainsi comprendre le code plus rapidement, donc un gain de temps est accompli.
En conclusion, nous pourrions dire que les rôles sont plus modernes que l’héritage, multiple ou non. Mais cela ne dépend pas que de code, mais aussi des techniques de développement. Si une grosse structure d’héritage est conçue élégamment et intelligemment, alors elle sera aussi simple à lire que si des rôles avaient été appliqué. Ce n’est donc qu’une histoire de pratique de programmation que l’on applique bien ou non. Mais si on veut se facilité la vie quand on débute, alors les rôles permettent de créer une base de code et également de perdre moins de temps à concevoir une structure d’héritage complexe.
Par Sandro
