[Effective Java 2] Item 16: Favor composition over inheritance

Bonjour,

J'ai acheté :
Effective Java 2nd Revised edition

On peut retrouver le code source de ce livre ici :
Code source Effective Java

Item 16: Favor composition over inheritance

Je n'ai pas le sentiment d'avoir compris grand chose à cet item.

D'après ce que j'ai cru comprendre l'exemple à suivre ce sont les classes :
ForwardingSet et InstrumentedSet
L'exemple à ne pas suivre c'est la class :
InstrumentedHashSet

ForwardingSet n'est qu'une class intermédiaire.
La class que l'on souhaite intégrer à InstrumentedSet c'est la class Set<E>.

Ai-je bien compris ?
Si je souhaite créer une class A composée avec une class B, je dois écrire une class interB qui implement la class B qui sera elle même implémentée dans A ?

Autre question.
Lorsque Joshua Bloch parle de composition, parle-t-il de la même chose que le design pattern composite, ou celà n'a rien à voir ?

J'ai aussi acheté ce livre que j'ai beaucoup apprécié.

Citation:

Envoyé par Pierre8r

D'après ce que j'ai cru comprendre l'exemple à suivre ce sont les classes :
ForwardingSet et InstrumentedSet
L'exemple à ne pas suivre c'est la class :
InstrumentedHashSet

Yep!

Citation:

Envoyé par Pierre8r

ForwardingSet n'est qu'une class intermédiaire.
La class que l'on souhaite intégrer à InstrumentedSet c'est la class Set<E>.

Plus exactement, ForwardingSet est ce qui correspond dans le design pattern à un Decorator (comme indiqué dans le livre). ForwardingSet supprime l'héirtage qui apparaissait dans IntrumentedHashSet et utilise la composition à la place. Le decorator permet ici d'éviter qu'apparaissent un comportement imprévu dû à l'héritage direct.

Citation:

Envoyé par Pierre8r

Ai-je bien compris ?
Si je souhaite créer une class A composée avec une class B, je dois écrire une class interB qui implement la class B qui sera elle même implémentée dans A ?

C'est ce que montre l'exemple, mais c'est un cas particulier. Je pense que la leçon a retenir de cet item est que l'héritage peut être aussi dangereux que les pointeurs en C.

J'ai eu à faire à un cas ou le développeur cherchait à créer une classe appelée Dictionnaire avec une méthode ajouterOccurence(mot) et getNombreDe(mot) pour compter le nombre de mots dans un texte. Le problème est que le développeur avait fait hériter sa classe de HashMap (ouch!). Du coup, la classe Dictionnaire se retrouvait avec des opérations qui risquaient de compromettre l'état de ses instances. En effet, un second développeur, sans forcément avoir une mauvaise intention, peut en toute légèreté écrire monDictionnaire.put(monMot, -150), au lieu d'appeler ajouterOccurrence(monMot) comme il aurait dû le faire... Pour résoudre ce ptoblème, il aurrait fallu ne pas faire hériter Dictionnaire de HashMap et créer à la place une variable d'instance à l'intérieur de Dictionnaire de type HashMap.

Il faut savoir que ce problème apparait aussi dans différentes classes de la bibliothèque standard de Java. Par exemple, java.util.Properties qui hérite de Hashtable.

Citation:

Envoyé par Pierre8r

Autre question.
Lorsque Joshua Bloch parle de composition, parle-t-il de la même chose que le design pattern composite, ou celà n'a rien à voir ?

Dans le livre, le terme composition est à prendre dans le sens où l'on crée une liaison entre une classe A et une classe B, en déclarant dans A une variable d'instance qui référence une instance du B.

Citation:

Je pense que la leçon a retenir de cet item est que l'héritage peut être aussi dangereux que les pointeurs en C.

C'est surtout que l'héritage décrit une relation forte entre deux classes, appelée "is a" (est un). Et souvent, on rencontre du code où l'héritage est utilisé sans que cette relation existe, ce qui est parfaitement incorrect de ce point de vue (est-un).