Composition over inheritance in OOP

Je te conseille la lecture du blog de Tom Butler et ses réflexions sur la programmation objet en général.
Pour résumé, il dit que la programmation telle qu'on l'utilise, même sur des gros projets comme Symfony, n'est pas la façon dont on devrait l'utiliser.
Ce qu'il faudrait c'est :

• Pas d'héritage. Plutôt que de dire l'objet B "est un" objet A, il faudrait se dire, l'objet B est "un objet qui a" ...
• Immutabilité des objets pour faciliter leur réutilisation et pouvoir être sûr de leur état quelle que soit l'étape d'un programme.
• Bannir les objets statics qui ne sont que de la programmation procédurale qui mime de l'objet

Est-ce que c'est la POO qui craint ou la manière dont elle est enseignée et mise en pratique ?
Le seul site qui m'a fait prendre conscience de ça est celui de Tom Butler qui montre que la POO n'est pas utilisée comme il le faudrait et que cela mène à des aberrations comme celles décriées dans les articles que tu cites.
Il suffit simplement de prendre deux fameux framework php qui utilisent la POO mais qui le font mal, et qui sont pourtant utilisés par nombres de développeurs : Symfony et CakePHP. Et de relire les articles de Tom pour voir ce qui ne va pas...

Parce que c'est null ! :-)

Encore un article qui démontre que tout ce que j'ai appris, ben, c'est de la merde.

Plutôt que de penser ses classes en terme d'héritage (est-un), il vaut mieux penser en terme de composition (possède-un ou est-composé-de).

L'héritage est une mauvaise pratique, le plus souvent, car cela rompt l'encapsulation et souvent engendre une répétition inutile de code (coucou Symphony, coucou Cake...).
La composition permet de l'éviter.

Le seul moment où il est nécessaire d'utiliser l'héritage est lorsque l'on n'a pas écrit la classe de base et que l'on doive modifier un de ses comportements sans pouvoir utiliser un patron d'adaptation.