IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 , par 3DArchi

0PARTAGES

0  0 
à 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 ?

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

Avatar de jblecanard
Membre expert https://www.developpez.com
Le 02/03/2010 à 15:00
Bonjour tous

Citation Envoyé par 3DArchi Voir le message
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...
0  0 
Avatar de gbdivers
Inactif https://www.developpez.com
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
0  0 
Avatar de Goten
Membre chevronné https://www.developpez.com
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()...
0  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
Le 03/03/2010 à 10:43
Citation Envoyé par gbdivers Voir le message
Moi pas tout comprendre mots à vous
faq + tutoriels + google
Citation Envoyé par gbdivers Voir le message

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.

Citation Envoyé par gbdivers Voir le message

PS : avis d'un non-informaticien qui a appris en auto-didacte
Comme beaucoup de développeurs avant le diplôme ... ou pas.
0  0 
Avatar de gbdivers
Inactif https://www.developpez.com
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
0  0 
Avatar de jblecanard
Membre expert https://www.developpez.com
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... ?
0  0 
Avatar de gbdivers
Inactif https://www.developpez.com
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.
0  0 
Avatar de jblecanard
Membre expert https://www.developpez.com
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).
0  0 
Avatar de 3DArchi
Rédacteur https://www.developpez.com
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.
0  0 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
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
0  0