Discussion :

[gbdivers]

Juste une correction sur la phrase de Christuff :

Pas pointeur = variable local donc constructeur appelé lors de la construction de la classe qui contient "tata objet;" : nécessite d'avoir un constructeur par défaut.

On peut créer un objet qui n'a pas de constructeur par défaut, soit directement dans le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MonObjetSansConctructeurParDefaut A("une chaine", 4, 10.2); // appel du constructeur MonObjetSansConctructeurParDefaut(const string&, const int, const double)

ou dans la liste d'initialisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MonAutreObjet:MonAutreObjet(...) : A("une chaine", 4, 10.2) { ... } // appel du constructeur MonObjetSansConctructeurParDefaut(const string&, const int, const double)

appuie toi sur autre chose que ton expérience

Je serais curieux aussi de savoir l'expérience de maske.

A lire et à relire : le forum Conception, le forum C++ et le blog d'Emmanuel. L'apprentissage de la programmation ne se limite à l'apprentissage d'une syntaxe.

[Emmanuel Deloget]

Je serais curieux aussi de savoir l'expérience de maske.

A ce sujet, et après discussion avec maske, je me rends compte que j'ai été inutilement dur dans mes propos. C'est une erreur de ma part, une erreur que maske m'a fait remarqué en privé, et je lui présente ainsi qu'à tous les lecteurs mes plus humbles excuses.

J'ai fustigé maske pour son arrogance, et, ce faisant, j'ai moi-même fait preuve d'une arrogance et d'une suffisance bien pire que celle que j'ai - à fortiori à tord - supposé. Je fait ici mon mea culpa, en espérant que vous y trouverez matière à me pardonner - et bien entendu, que maske accepte ces excuses.

[maske]

Ben moi je l'aime bien ce dynamic_cast. Ce qui m'intéresse c'est bien qu'il fasse planter mon programme s'il n'arrive pas à faire sa conversion.

Ce que je veux dire, c'est que le dynamic_cast m'intéresse dans ce cas là, et que l'utilisation de celui-ci avec des tests en compléments sont volontaires et voulus.

Je ne peux pas discuter sur ce sujet : effectivement, si tu est obligé d'utiliser une librairie dont le design est mauvais, tu peux ne pas avoir le choix. Si ce design de librairie est de ton initiative, alors tu as fait une erreur - et tu t'en rendra compte bien assez tôt.

Je ne suis pas adepte du cast à tout va, le problème est que dans de gros projets industriels, ceux qui fixent un paquets de règles n'habitent ni la porte, ni le bureau (ni forcément la ville ou le pays) d'à coté.

Et lorsqu'on a des couches qui inter-opèrent via des interfaces et des conventions fixées "à tout jamais" et que parfois, on ne fait pas confiance à ce qu'on en récupère, je vois un intérêt au dynamic_cast.

Les régressions (qui restent possibles) ne sont pas la seule raison valable. Plus un module est utilisé par d'autre, plus il est dit "stable". Si un module stable est modifié, il peut engendrer des surcoûts monstrueux. Je m'en rends compte sur mon projet actuel, où la modification nécessaire de l'interface d'une classe provoque la modification nécessaire de près de 30 modules, soit de l'ordre de 100 jours de charge. Un ingénieur a plein temps pendant 5 mois, c'est pas tout à fait gratuit.

Je suis bien d'accord, et c'est là mon problème. Les interfaces dont je parlais plus haut peuvent être fixes pour plusieurs raisons j'imagine, mais en particulier celle que tu invoques.

Moi ma spec change "souvent", et je dois modifier le code sans changer les interfaces vers des boites noires (donc pas touche), et en évitant les régressions.

En revenant sur le dynamic_cast, j'ai tendance (à tord ?) à l'utiliser comme une sécurité supplémentaires dans certains de ce genre de cas.

TDD n'a pas d'impact sur l'architecture logicielle objet, je ne vois donc pas comment TDD pourrait avoir un impact sur les principes qui la sous-tende.

Pour moi écrire le test avant le code ne peut pas engendrer de modifications sur ce dernier, qui n'existe pas encore. Je n'ai jamais fait de TDD cependant, d'où la question.

les tests ne couvrent pas tout, et il n'est pas rare de trouver des bugs dans un code qui a pourtant été rigoureusement testé. D'autre part, une modification n'a pas que des impacts sur les tests.

Pareil si tu mets le code dans des fichiers ZIP et que tu archives ces fichiers dans un répertoire de ton PC. Mais quel est le rapport avec le sujet ?

Je veux dire que avec une couverture de tests et une gestion en configuration, on peut aborder les modifications de code plus sereinement que dans le cas contraire.

En ce qui concerne le contrôle d'accès aux attributs d'un objet, c'est une possibilité qui rendent C++ et Java bâtards niveau OO - comparé à Smalltalk par exemple - l'objet n'est plus vu comme une boite noire parce que si on veut, on met les attributs en public au lieu de privé pour éviter de se taper des accesseurs (faut arrêter vi et passer sous un éditeur qui les génère automatiquement !), et ce sans justification réelle autre que "les accesseurs ça sert à rien et ça me fait chier".

Quelles sont les raisons qui peuvent objectivement pousser à ne pas utiliser d'accesseurs ?

La question est donc : l'encapsulation ne rend-elle pas le code plus simple à écrire et à maintenir ?

J'aurais du poser ma question comme ça. En fait c'était une réaction à ce que tu as dit à un moment, à savoir qu'il serait possible d'écrire un article sur la pertinence d'utiliser des accesseurs. J'aurais voulu avoir des éléments là dessus.

Pour l'instant, les personnes que j'ai vu ne pas le faire n'avaient pour seule raison que "la flemme, et puis ça ne sert à rien" - sans vouloir généraliser.

Créer des accesseurs est aujourd'hui assez facile et automatique avec la plupart des gros EDI, et quand un changement de nom intervient, un refactoring automatique est en général possible.

Run Time Type Identification

Ok, je ne connaissais pas.

J'accepte les excuses bien évidemment mais je ne voulais pas forcer à cela.

Je serais curieux aussi de savoir l'expérience de maske.

Courte.