Discussion :

[3DArchi]

[suite à cette discussion ]
Salut,
Beaucoup de framework, notamment IHM (Qt, wxWidgets, MFC) sont construits autour d'une super classe de laquelle héritent toutes ou parties des classes du framework. Que pensez-vous de cette pratique ? Est-ce une bonne chose dans l'architecture de vos logiciels ?
Personnellement, je pense qu'il s'agit d'une pratique présentant plus d'inconvénients que d'avantages. Et vous ?

[poukill]

P.S. : quand on a un projet où tous les objets dérivent de ObjetBase, c'est mal barré d'un point de vue conception.

Ah ? Mais si tu veux que toutes tes classes implémentent quelque chose comme GetTypeName().
Perso j'ai une classe IObject dont 99 % des classes de mon projet dérivent. Au début ça m'a fait bizarre, mais c'est très pratique. Bonne combinaison avec ma factory et tout ce qui va avec...

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
 
#ifndef OBJECT_H
#define OBJECT_H
 
#include <string>
 
#include <boost/shared_ptr.hpp>
 
#define DECLARE_TYPE(Class) \
	virtual std::string GetTypeName() const {return #Class; }
 
#define DECLARE_CLONE(Class) \
	virtual boost::shared_ptr<IObject> Clone() const {return boost::shared_ptr<IObject>(new Class(*this)); }
 
 
 
//-----------------------------------------------------------
// IObject : Base class
//-----------------------------------------------------------
 
struct IObject
{
	IObject() {}
	virtual ~IObject() {}
 
	// Fonction to get the real type of the Class.
	virtual std::string					GetTypeName	() const = 0;
 
	// Polymorphic copy the object
	virtual boost::shared_ptr<IObject>	Clone		() const
	{
		throw std::exception("This object is no clonable");
	}
 
};
 
typedef boost::shared_ptr<IObject> object_ptr;
 
 
#endif

[gbdivers]

Ce qui serait étrange, c'est que toutes tes classes dérivent directement de ton IObject

Code :

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

class MaClass : public IObject, (...)

Par contre, qu'une classe dérive d'une classe qui dérive d'une classe qui dérive (...) qui dérive de IObject, ça ne pose pas de problème.

Un exemple : dans Qt, la majorité des classes dérivent de QObject (pour pouvoir utiliser les meta infos, les signaux/slots, etc.)

[3DArchi]

Ah ? Mais si tu veux que toutes tes classes implémentent quelque chose comme GetTypeName().

Ce qui serait étrange, c'est que toutes tes classes dérivent directement de ton IObject

Code :

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

class MaClass : public IObject, (...)

Par contre, qu'une classe dérive d'une classe qui dérive d'une classe qui dérive (...) qui dérive de IObject, ça ne pose pas de problème.

Un exemple : dans Qt, la majorité des classes dérivent de QObject (pour pouvoir utiliser les meta infos, les signaux/slots, etc.)

Beaucoup de framework ont des classes de ce genre : QObject (Qt)/wxObject (wxWidgets)/CObject (MFC). Mais, j'avoue que ça me laisse toujours dubitatif. Ca n'est pour moi pas très loin d'un void* d'un point de vue conception. Et comme tu le dis, la plus part du temps, ces objets n'ont qu'une ou deux fonctions de type info de classe ou clone. Elles ne peuvent avoir d'ailleurs pas vraiment d'autres fonctions car ils n'y a pas grand chose d'autre à factoriser. En plus tu obliges à de l'héritage et introduits des vtable là où il n'y en a peut être pas besoin.
Je me demande si je ne préfèrerais pas passer alors par une classe trait pour définir et retrouver ces infos.

[jblecanard]

Bonjour tous

Salut,P.S. : quand on a un projet où tous les objets dérivent de ObjetBase, c'est mal barré d'un point de vue conception.

Pas du tout. Comme le disent d'autres rédacteurs, c'est beaucoup utilisé dans de gros projets, car celà permet par exemple d'ajouter une gestion du cycle de vie des objets plus fine, de tracer leur existence en mode dev, etc...

[3DArchi]

Pas du tout. Comme le disent d'autres rédacteurs, c'est beaucoup utilisé dans de gros projets, car celà permet par exemple d'ajouter une gestion du cycle de vie des objets plus fine, de tracer leur existence en mode dev, etc...

Que des fonctions qui n'ont rien à voir avec un héritage public...
Je maintiens que faire dériver publiquement tous ses objets d'un MyGodObject est une erreur de conception ou, disons, une facilité de conception qui dans 99,9% des cas peut être abordée autrement.

[jblecanard]

Que des fonctions qui n'ont rien à voir avec un héritage public...

Pas exactement. Si tu veux gérer un compteur de référence par exemple, en appelant une méthode quand tu ajoute une référence et une autre pour la libérer, il faut que ton héritage soit public.

Après, si ta conception est "plate" et que tous les objets héritent tous directement du même parent, là d'accord il y a quelque chose qui ne va pas. (edit clarté)

[gbdivers]

Un exemple de d'héritage public : dans Qt, faire dériver la majorité des objets de QObject permet de profiter les méta infos et des signaux/slots par exemple.

une facilité de conception qui dans 99,9% des cas peut être abordée autrement

Je suis d'accord qu'il s'agit d'une facilité et qu'il ne faut pas l'utiliser quand c'est pas nécessaire (et qu'il faut se poser la question, si on utilise ce type d'approche, de savoir s'il n'y a pas un problème de conception).

Mais dans un framework (Qt, wx, MFC que tu citais), ce système permet quand même une grande souplesse et facilite son utilisation, ce qui n'est pas négligeable pour que le framework soit plus largement utilisé (les utilisateurs ne veulent pas forcement passer des semaines à lire la doc pour pouvoir utiliser le framework).

Par exemple, pour les métas infos et les signaux/slots de Qt, comment aurais-tu fait à la place sans hériter d'un QObject arrière-arrière-arrière-...-arrière-grand-parent ?
(ma question n'est pas totalement désintéressée je travaille actuellement sur une nouvelle version d'un framework pour le passer d'une version 1 qui utilise beaucoup les template mais qui est particulièrement complexe à utiliser, à une version 2 qui utilisera ce système. J'espère beaucoup gagner en facilité d'utilisation pour un cout en temps faible)

[Laurent Gomila]

Par exemple, pour les métas infos et les signaux/slots de Qt, comment aurais-tu fait à la place sans hériter d'un QObject arrière-arrière-arrière-...-arrière-grand-parent ?

Pour les signaux/slots, boost.signal + boost.bind. Pas besoin d'une classe de base pour gérer ce genre de choses.
Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive. J'en ai moi-même écrit une il y a quelques temps. Sinon, on peut faire comme Qt et faire tourner un précompilateur pour extraire ces informations automatiquement ; là aussi il existe quelques projets open-source qui tournent pas mal.

Le problème de Qt c'est qu'il a une base assez ancienne et que tout le reste repose dessus, ce serait carrément inenvisageable qu'ils se mettent à repenser leur système de QObject. Mais le fait est qu'avec du C++ moderne on peut faire mieux.

[3DArchi]

Pour les signaux/slots, boost.signal + boost.bind. Pas besoin d'une classe de base pour gérer ce genre de choses.
Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive. J'en ai moi-même écrit une il y a quelques temps. Sinon, on peut faire comme Qt et faire tourner un précompilateur pour extraire ces informations automatiquement ; là aussi il existe quelques projets open-source qui tournent pas mal.

Le problème de Qt c'est qu'il a une base assez ancienne et que tout le reste repose dessus, ce serait carrément inenvisageable qu'ils se mettent à repenser leur système de QObject. Mais le fait est qu'avec du C++ moderne on peut faire mieux.

Plus les classes traits + dans certains cas la programmation orientée aspect peut aussi apporter des solutions + interface clonable si besoin uniquement pour les sémantiques d'entité (laisser la copie pour les sémantiques de valeur), +les infos de types dynamiques, etc.

les utilisateurs ne veulent pas forcement passer des semaines à lire la doc pour pouvoir utiliser le framework

Vu que nous avons des forums pour chacun de ces frameworks et vus le nombre de questions qu'ils génèrent, je pense qu'au final si, on passe des semaines à lire de la doc

[gbdivers]

Pour les meta-informations, il existe des bibliothèques qui implémentent une pseudo-reflexion sur les membres de manière presque pas intrusive

Plus les classes traits + dans certains cas la programmation orientée aspect peut aussi apporter des solutions + interface clonable si besoin uniquement pour les sémantiques d'entité (laisser la copie pour les sémantiques de valeur), +les infos de types dynamiques, etc.

Moi pas tout comprendre mots à vous

Plus sérieusement, je connais certaine de ces notions mais elle me semble quand même être d'un certain niveau.
Effectivement, on peut se passer des super-objets pour faire la même chose (j'ai regardé un peu boost.signal que je connaissais pas... j'utilise jamais boost )
Mais j'ai l'impression, en regardant les examples donnés dans la doc de boost.signal, qu'il s'agit au final de faire la même chose... en plus de lignes et en plus compliqué (mais c'est peut être parce que j'utilise Qt et non boost que j'ai cette impression, je suis plus habitué à la première manière).

Au final, l'argument pour justifier les super-objets, ça reste la facilité de conception (pour un cout mémoire/temps non critique, surtout pour une ihm)
Personnelement, j'ai opté pour une lib avec super-objets (wx avant, Qt maintenant) plutot que boost (par exemple) qui me semble beaucoup plus difficile à appréhender

PS : avis d'un non-informaticien qui a appris en auto-didacte

[Goten]

Boost signal plus de ligne? Si ça peut m'éviter de devoir utiliser un compilateur dédié (systéme MOC de Qt) et des macros je préfère...

Quand à la problématique de départ il suffit de voir les soucis qu'ont les javaistes avec equal()...

[3DArchi]

Moi pas tout comprendre mots à vous

faq + tutoriels + google

Au final, l'argument pour justifier les super-objets, ça reste la facilité de conception (pour un cout mémoire/temps non critique, surtout pour une ihm)
Personnelement, j'ai opté pour une lib avec super-objets (wx avant, Qt maintenant) plutot que boost (par exemple) qui me semble beaucoup plus difficile à appréhender

Disons que les frameworks (Qt, wx, MFC) ont un historique qui amène à cet état de fait. Et comme le dit Laurent, ben maintenant, ça ne va pas changer.

PS : avis d'un non-informaticien qui a appris en auto-didacte

Comme beaucoup de développeurs avant le diplôme ... ou pas.

[gbdivers]

Comme beaucoup de développeurs avant le diplôme ... ou pas.

Je ne suis plus étudiant (et je n'ai pas étudié l'informatique)

C'est peut être pour cela que j'ai un avis différent du votre : cela me gène pas d'utiliser des super-objets, des pré-compilateur (tant que c'est transparent) ou des macros.
Par contre, ça me gène plus de devoir utiliser plusieurs libs différentes, d'augmenter le nombre de lignes de code ou de devoir utiliser des notions complexes.
Mon objectif reste quand même d'obtenir le résultat voulu, même si c'est moins propre. En plus, c'est portable et plus facile à maintenir.
Le framework sur lequel je travail actuellement (je viens de rejoindre l'équipe de dev) n'utilse pas par exemple les super-objets pour les méta-infos (classe home-made dédiée). Et je trouve ça très lourd à utiliser et à maintenir. Et j'espère (si j'arrive à convaincre l'équipe de dev) que l'on passera à un fonctionnement en super-objet (probablement QObject pour ne pas avoir à réécrire un équivalent).

faq + tutoriels + google

Pas d'inquiétude, je soigne mon manque de connaissance. progressivement

[jblecanard]

Voilà qui est fort intéressant...

Et quelle solution "moderne" utilisez vous si vous voulez standardiser la gestion du cycle de vie des objets dans votre projet ? Les smart pointers de boost ont l'air bien, quid on veut gérer l' add_ref/release à la main, suivre les compteurs, etc... ?

[gbdivers]

J'avoue ne pas très bien comprendre la question... (si c'est bien à moi que la question est posée)
La gestion du cycle de vie des objets dépendent avant tout du logiciel et de sa conception. Un framework apporte (ou pas) des outils pour faciliter cette gestion. Donc on peut utiliser ce qu'on veut (pointeurs bêtes, pointeurs intelligent de boost ou de Qt, etc.)

L'utilisation d'un framework (avec ou sans super-objets) n'interdit pas d'utiliser également d'autres libs en plus.

[jblecanard]

Je pose la question à tout le monde en fait.

Utiliser un super objet peut être une technique pour gérer le cycle de vie : le super objet va contenir un compteur de références, modifiable via des add_ref/release. Cela fournit une API identique de TTL sur tous les objets du projet. Pas besoin d'une table virtuelle supplémentaire (il n'y a pas de raisons que les objets enfants aient à écraser les addref/release existants), et la quantité de données supplémentaires n'est pas énorme (un int), sans rajouter pour autant une indirection supplémentaire lors des appels de méthodes.

Bien sûr, on peut utiliser depuis le départ les smarts pointers de boost par exemple, mais on n'a pas la main sur les compteurs de référence. On pourrait imaginer un mécanisme ou les objets "s'enregistrent" auprès d'un conteneur qui peut les lister et faire d'autres opérations (ça peut être intéressant pour faire du profiling).

[3DArchi]

Pas besoin d'héritage publique. Un héritage privé suffit alors. Je te l'accorde, ce n'est pas beaucoup mieux. Disons que c'est un peu moins pire.
Typiquement, je préfère utiliser un pointeur intelligent à part (boost, qt ou autre).
Et quitte à faire du profiling, je préfère alors instrumenter le pointeur intelligent et pas toutes les classes en leur imposant de dériver d'une super classe. En plus, pour du profiling - dont je n'aurais pas besoin à priori en prod -, peut être que d'autres approches peuvent se révéler plus intéressantes (par expl, la prog par aspect).
Disons qu'il n'y a pas forcément THE solution au remplacement d'une super classe. Cela dépend du problème, de l'architecture du soft, du contexte du projet, etc. En revanche, je pense qu'obliger toutes ses classes à dériver d'une super classe fragilise l'architecture du logiciel en l'ossifiant et la rendant moins réutilisable.

[koala01]

Salut,

Je vois personnellement trois gros problèmes au recours d'un god_object...

Le premier a déjà été évoqué consiste en la création d'une vtable qui pourrait ne pas s'avérer utile /nécessaire

Le second pointe certaines restrictions que peut imposer la technique, au sujet par exemple de l'héritage multiple ou en diamant, avec la nécessité de passer par un héritage virtuel

Le troisième est que l'on en arrive à une hiérarchie de classes sur un tel nombre de niveau que l'on finit par avoir des interfaces beaucoup trop complexes pour les classes qui se trouvent "en bas" de la hiérarchie, et pour lesquelles une grande quantité de membres n'ont, en définitive, qu'un intérêt particulièrement limité.

Je ne dis pas que certains membres n'auront aucun intérêt, mais bien qu'ils n'auront qu'un intérêt très restreint dans "l'utilisation quotidienne".

Prenez n'importe quelle classe concrète de Qt, par exemple, et amusez vous à faire le compte de toutes les méthodes, propriétés et membres qu'elles contient, même si on s'en tient à l'interface publique, et amusez vous à réfléchir un peu correctement aux cas dans lesquels vous pourriez y recourir...

Dans de nombreux cas, vous allez limiter l'utilisation de l'interface à quelques méthodes à peine, et un bon 80% du reste ne sera que d'une utilisation marginale.

Serais-je le seul à estimer qu'un tel rapport entre le nombre de fonctions utiles et le nombre de fonctions marginal a quelque chose d'aberrant

[Goten]

Je pose la question à tout le monde en fait.

Utiliser un super objet peut être une technique pour gérer le cycle de vie : le super objet va contenir un compteur de références, modifiable via des add_ref/release. Cela fournit une API identique de TTL sur tous les objets du projet. Pas besoin d'une table virtuelle supplémentaire (il n'y a pas de raisons que les objets enfants aient à écraser les addref/release existants), et la quantité de données supplémentaires n'est pas énorme (un int), sans rajouter pour autant une indirection supplémentaire lors des appels de méthodes.

Bien sûr, on peut utiliser depuis le départ les smarts pointers de boost par exemple, mais on n'a pas la main sur les compteurs de référence. On pourrait imaginer un mécanisme ou les objets "s'enregistrent" auprès d'un conteneur qui peut les lister et faire d'autres opérations (ça peut être intéressant pour faire du profiling).

boost::intrusive_ptr .. ?

Mais comme le précise la doc de boost, c'est rare de vouloir avoir la main sur le compteur de références ... il vaut mieux avant prévoir un design à partir de shared_ptr..

Pis si je dois tout dériver d'un seul objet juste pour du ref counting, un peu overhead pour moi...