D'une manière générale, la conception des programmes informatiques telle qu'elle est trop souvent enseignée en se focalisant sur des détails triviaux et parfois hors sujets (car les sujets difficiles peuvent être et sont le plus souvent dans des domaines totalement distincts) de COO à la C++ ou Java est extrêmement préoccupante et a bien du faire perdre 10 à 20 ans à l'évolution des compétences moyennes des programmeurs.
Le problème de ce type de conception est qu'elle tend à produire des programmes à l'architecture naives car n'ayant trop peu de structure de plus haut niveau, et l'architecture induite par une simple hiérarchie de classe n'est guère plus structurante qu'une architecture basée sur une programmation par découpage hiérarchique en fonctions (et parfois elle peut même l'être moins). Du coup les étudiants affectés ont la fausse sensation, n'ayant que travaillés pour la plupart sur des projets simples pour lesquels se contenter d'une telle hiérarchie ne pouvait pas plus faire de mal que n'importe quelle autre approche, que le découpage en hiérarchie de classe est une bonne chose quasi-absolue voire même suffit voire même ils sont totalement aveuglés au point de dénigrer des approches supérieures. Certains langages ne facilitent pas la tache en rendant exagérément facile leur approche native et contre intuitifs et nécessitant un apprentissage spécifique les autres patterns, ou encore en fournissant des mécanismes de résolution d'une classe restreinte de problèmes qui "anesthésie" de par la terminologie employé (et quelques fois même par un mauvais enseignement les indiquant là où ils ne suffisent pas) l'utilisateur vis à vis d'une classe plus grande de problèmes, que du coup il ne traite pas, conduisant au fil du temps à une mauvaise architecture irrattrapable (ex : private / protected / public à la C++ n'est pas intrinsèquement une mauvaise chose mais trop souvent c'est employé là ou en fait une vraie structure opaque et de la vraie modularité seraient infiniment supérieures, et ceux dans toutes les phases du développement).
[^] # Re: Plusieurs
Posté par Guillaume Knispel . En réponse au journal Le problème de la POO pratiquée par des étudiants. Évalué à 1.
D'une manière générale, la conception des programmes informatiques telle qu'elle est trop souvent enseignée en se focalisant sur des détails triviaux et parfois hors sujets (car les sujets difficiles peuvent être et sont le plus souvent dans des domaines totalement distincts) de COO à la C++ ou Java est extrêmement préoccupante et a bien du faire perdre 10 à 20 ans à l'évolution des compétences moyennes des programmeurs.
Le problème de ce type de conception est qu'elle tend à produire des programmes à l'architecture naives car n'ayant trop peu de structure de plus haut niveau, et l'architecture induite par une simple hiérarchie de classe n'est guère plus structurante qu'une architecture basée sur une programmation par découpage hiérarchique en fonctions (et parfois elle peut même l'être moins). Du coup les étudiants affectés ont la fausse sensation, n'ayant que travaillés pour la plupart sur des projets simples pour lesquels se contenter d'une telle hiérarchie ne pouvait pas plus faire de mal que n'importe quelle autre approche, que le découpage en hiérarchie de classe est une bonne chose quasi-absolue voire même suffit voire même ils sont totalement aveuglés au point de dénigrer des approches supérieures. Certains langages ne facilitent pas la tache en rendant exagérément facile leur approche native et contre intuitifs et nécessitant un apprentissage spécifique les autres patterns, ou encore en fournissant des mécanismes de résolution d'une classe restreinte de problèmes qui "anesthésie" de par la terminologie employé (et quelques fois même par un mauvais enseignement les indiquant là où ils ne suffisent pas) l'utilisateur vis à vis d'une classe plus grande de problèmes, que du coup il ne traite pas, conduisant au fil du temps à une mauvaise architecture irrattrapable (ex : private / protected / public à la C++ n'est pas intrinsèquement une mauvaise chose mais trop souvent c'est employé là ou en fait une vraie structure opaque et de la vraie modularité seraient infiniment supérieures, et ceux dans toutes les phases du développement).