Et paf, ça à fait des chocapic.
Le déclic, j'ai compris que
1) les profs de mes souvenirs appliquaient bêtement un principe et le rendaient ainsi caduque, rendant le code plus lourd à manipuler (bah oui, des setter et getter qui ne font que lire ou écrire sans traitement un membre, c'est pire que le mettre en public pour moi). et écrire.
2) la solution, c'est de considérer que le nom des variables interne n'a absolument pas à être connu. "getName()"? Mais quelle horreur! Le nom "name()" est bien meilleur, pour moi. C'est un getter dans le rôle, mais plus dans le nom. Et le setter, c'est "rename(std::string const&)", pas "setName(...)".
3) conséquence de 2, j'ai compris que nombre de getter/setter peuvent juste renvoyer un résultat bâti en direct, sans nécessiter de stockage.
4) ces codes sont plus simples à écrire et maintenir si l'on évite de faire plus d'une chose par méthode/fonction. Conséquence: des fonctions de 20 lignes en moyenne.
5) quand on commence à discerner des jeux de fonctions utilisant des jeux de membres, c'est qu'il y a une classe à créer.
C'est malheureux, mais si j'appliquais bêtement le bourrage de crâne auquel j'ai assisté, plutôt que de merder à pondre du code dégueu un temps, mon code serait encore plus bourré d'anti-pattern et de doctrine qu'il ne l'est actuellement. Bon, ok, a l'heure actuelle, il n'est pas trop endoctriné, par contre je ne parierais pas au sujet des anti-pattern.
Partager