Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les architectures à base d'un SuperObjet offrent-elles plus d'avantages que d'inconvénients ?

Le 26 février 2010 à 06:36, par 3DArchi

142 commentaires

42PARTAGES

[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 ?

Vous avez lu gratuitement 7 446 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

142 commentaires

Commenter Signaler un problème

jblecanard

Membre expert

Le 02/03/2010 à 15:00

Bonjour tous

Envoyé par 3DArchi

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...

gbdivers

Inactif

Le 03/03/2010 à 10:32

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

Membre chevronné

Le 03/03/2010 à 10:38

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

Rédacteur

Le 03/03/2010 à 10:43

Envoyé par gbdivers

Moi pas tout comprendre mots à vous

faq + tutoriels + google

Envoyé par gbdivers

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.

Envoyé par gbdivers

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

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

gbdivers

Inactif

Le 03/03/2010 à 11:13

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

Membre expert

Le 03/03/2010 à 11:26

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

Inactif

Le 03/03/2010 à 13:14

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

Membre expert

Le 03/03/2010 à 13:38

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

Rédacteur

Le 03/03/2010 à 15:13

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

Expert éminent sénior

Le 03/03/2010 à 15:20

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

Commenter Signaler un problème