-
Héritage
Bonjour,
J'ai un programme avec des classes dont la hiérariche est assez flagrante. COmme au début les différences entre les sous classes étaient très petites et que le nombre de sous classes etait grand (environ 20), j'ai décidé de ne pas faire d'héritage et à ajouter une variable int type. Le problème c'est que petit à petit des différences apparaissent, et que je commence a avoir des switch(type) un peu partout. Au dela des considérations habituelles sur la présentation du code, je me demandais si de cette facon mon code était plus lent ou pas, puisque la je dois faire en moyenne 10 comparaisons pour trouver le bon type, et je ne sais pas combien de temps il faut pour trouver la bonne sous classe (accès direct?).
Je sais pas si j'ai été très clair, pourtant je sais que c'est assez clair dans ma tête :)
Qu'en dites vous?
-
Ca me paraît pas terrible (et pas maintenable, flexible, ...) comme design Niveau performances je pense que c'est pas terrible non plus, même si dans 99% des cas ce sera de toute façon négligeable.
Habituellement on essaye de jouer avec le polymorphisme, mais bien entendu ça dépend du contexte. Tu peux décrire un peu plus ton problème ainsi que ta hiérarchie de classes ?
-
Ma hiérarchie c'est une classe Controle et des sous classes "Bouton", "Liste", "Edit"...
Ces sous classes ont toutes les mêmes types de données jusqu'à maintenant, c'est pour ca que je n'ai pas fait de sous classe.
Par contre j'ai plein de tableau de type:
char* defaultText[] = {"Bouton", "Liste", "Zone d'édition"};
int defaultSize[] = {70, 100, 100};
et
#define BUTTON 0
#define LIST 1
#define EDIT 2
et une donnée type parmis {BUTTON, LIST, EDIT}, de telle sorte que je fais par exemple defaultText[type] ou defaultSize[type] pour avoir la valeur appropriée.
-
Ici, le switch est définitivement un mauvais désign. Surtout quand on commence à avoir besoin d'autant de widgets spécialisés.
Au fait, pourquoi réinventer la roue ? Ce n'est pas comme si il en manquait (QT, GTK+, win32gui, Adam & Eve, wxWidgets, plus tous les frameworks payants et propriétaires)
-
Pkoi utiliser le c++ si c'est pour faire une telle horreur :lol:.
Je plaisante mais quand on utilise un langage objet autant profiter de ses qualités.
-
Je ne réinvente rien, j'utilise ceux de Windows mais comme fais un editeur de Dialogue, j'ai besoin de sous-classer tous les contrôles
Comme je l'ai dit au début, le design je m'en fous un peu, ce qui m'intéresse c'est juste la performance de mon code
-
Vous avez raison, j'ai décidé d'utiliser l'héritage. Il me reste un truc assez lourd, savez vous s'il y a un moyen de faire ca plus proprement:
Window* w;
switch(n)
{
case 1:
w = new Button();
break;
case 2:
w = new Edit();
break;
...
}
(je veux parler d'une sorte de tableau t de classes, pour faire w = new t[n]())
-
Une factory ?
(Pour ce qui est des vitesses, inutile de faire des optimisations sans avoir mesurer lesquelles devaient être mises en place. De toutes façons, un code maintenable est 100 fois préférable à un code rapide.)
(Et sinon, google -> "n1359 C++", pour ce qui est des performances des constructions du C++)
-
Une factory? Ca me dit rien du tout, tu peux préciser ou me diriger quelque part?
Merci
-
C'est discuté de temps à autres (-> recherche avancée). Il faut regarder du côté des design patterns. C'est classique et à connaitre.
Loulou a un tutoriel qui présente les flyweight factory de sûr, pour les plus générales, je ne sais plus.
Dans un coin de mon site, j'ai une implémentation à 3/4 finie (il manque les créateurs flyweight) et dont la doc doit être réécrite. Elle est inspiré de celle présentée dans Modern C++ Design par Andrei Alexandrescu (et donc dans loki) et d'un vieil article du défunt C++ Report. factory.hpp (fichiers de tests); elle vaut ce qu'elle vaut.
La version simple correspond à un switch. La plus complexe (traitée dans les liens que j'ai donnés) consiste à enregistrer des créateurs d'objets dans une map (ou assimilé).
-