J'ai besoin d'intimité. Non pas parce que mes actions sont douteuses, mais parce que votre jugement et vos intentions le sont.
5139 links
Composition over inheritance in OOP
Un objet doit être immuable mais tout n'est pas toujours aussi tranché. Il peut y avoir des nuances...
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 :
Bien ce site !
Via l'ami Bronco
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...
Salut les potos,
Je me suis mis en tête de développer un framework from scratch en essayant d'appliquer au maximum les recommandations de Tom Butler sur la POO.
C'est encore dans son jus et les plâtres ne sont pas encore secs. Mais normalement, c'est fonctionnel.
N'hésitez pas à me dire ce que vous en pensez. Est-ce que je fais fausse route ? Est-ce que vous voyez des corrections/améliorations à apporter ?
Quand j'aurai un peu de temps, j'essaierai de faire un readme un peu plus étoffé. Mais en attendant, le code est commenté. Il faut une base MySQL. Un exemple de tables est donné dans le code.
Dans l'attente de vos retours.
Parce que c'est null ! :-)
Tout est dit.
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.
Pourquoi l'encapsulation est nécessaire aux objets et qu'il faut faire en sorte de ne pas la rompre.