Ça peut être sain, mais pourquoi devoir faire de l'héritage en faisant une tâche bien définie ? En utilisant l'héritage, est-ce que l'on ne tombe pas quelque part dans une « réinvention de la roue » ? Je veux dire , si on a besoin de deux classes pour faire deux choses différentes, l'héritage n'apporte pas grand chose là dedans.
Par exemple, j'ai l'impression que avec QT, l'héritage est très utilisé, mais brouille peut être un peu les pistes. On se retrouve avec x qui hérite de y et ainsi de suite, sans y voir une cohérence claire dès le début. Enfin ce n'est que mon avis, peut être que l'héritage apporte quelque chose si on se place d'un point de vue ensembliste pour le code. Ça simplifie peut être aussi l'appréhension du code par un humain.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.
[^] # Re: Héritage...
Posté par dave . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 1.
Ça peut être sain, mais pourquoi devoir faire de l'héritage en faisant une tâche bien définie ? En utilisant l'héritage, est-ce que l'on ne tombe pas quelque part dans une « réinvention de la roue » ? Je veux dire , si on a besoin de deux classes pour faire deux choses différentes, l'héritage n'apporte pas grand chose là dedans.
Par exemple, j'ai l'impression que avec QT, l'héritage est très utilisé, mais brouille peut être un peu les pistes. On se retrouve avec x qui hérite de y et ainsi de suite, sans y voir une cohérence claire dès le début. Enfin ce n'est que mon avis, peut être que l'héritage apporte quelque chose si on se place d'un point de vue ensembliste pour le code. Ça simplifie peut être aussi l'appréhension du code par un humain.
Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.