Discussion :

[hunter99]

Slt ,dans le cours de c++ le prof a dit qu'une classe est bien construite si elle satisfait 4 ou 5 règles mais je n'arrive pas a les remémorer.
Est ce que quelqu'un peut me el dire svp ?
Merci d'avance.
ps:j'ai déja fait une recherche sur google sans resultat.

[Pacorabanix]

ben une partie de la réponse est :

la classe est conçue pour présenter une INTERFACE (des méthodes publiques) de sorte que l'objet soit simple à utiliser par les programmeurs qui en ont besoin. Le reste, le pourquoi du comment la classe fonctionne, c'est l'implémentation , et ceci est censé etre caché. Ou en tout cas il ne devrait pas y avoir besoin de connaitre l'implémentation pour utiliser l'interface.


De sorte qu'une modification de l'implémentation est possible par le créateur de la classe, sans que ça nécessite une modification du code qui utilise la classe (juste recompiler /relinker vers la nouvelle classe modifiée).

Dans tous les cas, l'utilisateur de la classe ne DOIT PAS avoir accès aux données et aux fonctions utilitaires qui ne répondent pas directement aux buts publics de la classe.


Il faut qu'elle fasse ce qu'il faut qu'elle fasse, ni trop ni pas assez (un peu comme une fonction). Si c'est "trop" alors on peut probablement créer une classe à part pour le boulot qui est fait en trop.

C'est juste un outil pour concevoir un programme (développer) proprement. Après je ne crois pas qu'un développeur C++ a ses "5 commandements de classes" accroché au dessus du lit. (appel à témoignage ! )

[Alp]

Comme dit dans le message précedent, il ne faut pas surcharger de responsabilités une classe. Il faut qu'elle satisfasse un minimum de responsabilité.

Exemple : une classe socket ne doit pas gérer le stockage de données. Le socket doit récupérer les données et être capable de transmettre ces données à une classe qui s'occupera de les trier, et une autre qui les stockera, etc.

[Luc Hermitte]

Après je ne crois pas qu'un développeur C++ a ses "5 commandements de classes" accroché au dessus du lit. (appel à témoignage ! )

Disons que l'on a des recettes toutes faites selon les situations dans lesquelles nous nous trouvons. On rejoint patterns et idiomes.

Le rôle de l'interface est effectivement primordial. Ceci dit l'interface (publique généralisée) de manipulation concerne aussi les fonctions libres, et les propriétés (pouvant être mises en oeuvre par des attributs publics à accès direct, ou des privés à accès réglementés par des paires (ou non) d'accesseurs/mutateurs).
On peut aussi parler de rôles, et il est imporant que chaque classe aient des rôles clairs et bien définis.

La maitrise de la duplication est relativement importante en C++. On rejoint d'ailleurs les recettes dont je parlais juste avant.
- sémantique de valeur -> rien de particulier à faire, sauf si on est responsable d'une ressource brute (cf règle des 4, 3 ou 2 selon les raffinements successifs de la forme canonique de Coplien)
- sémantique d'entité -> par défaut, nul besoin de dupliquer => interdiction ; selon les cas, on clone.
- hiériarchie polymorphe => sémantique d'entité par défaut.

(je parle de cela car il n'est pas impossible que les "5 règles" ("du prof", façon de parler) concernent la forme canonique de Coplien... dont les conditions d'application ne sont pas si universelles -- à moins que l'interdiction soit une variante reconnue de la forme)

Il y a d'autres grands principes de conception OO qui me viennent à l'esprit -> LSP, Open-Closed Principle, couplages, etc.
Mais j'avoue qu'il est difficile de deviner ce dont on a pu te parler en cours.

PS: quand tu auras retrouvé ton support de cours, je serais curieux de savoir quels seraient les 4 ou 5 règles dont on t'avais parlé.