Discussion :

[koala01]

Salut,

Voilà, nous commençons à rentrer dans le vif du sujet...

En effet, le simple exemple de la gestion du positionnement a clairement mis en évidence le besoin d'adopter certains patrons de développements.

Le premier groupe de patrons dont le besoin a été mis en évidence se compose du visiteur, du médiateur et du composite.

En effet, il faut bien se rendre compte qu'il y aura régulièrement une relation de "contenant" à "contenu" qui entrera en ligne de compte, principalement entre les différents éléments visuels.

De ce fait, nous pouvons décemment estimer que le contenant agira tantôt comme un médiateur entre les différents éléments qu'il contient, tantôt comme simple visiteur de ceux-ci, et qu'enfin, le contenu peut parfaitement être... le contenant d'autre chose

Aucun de ces patrons de conception n'est en général réellement difficile à mettre en oeuvre, si ce n'est qu'ils s'appuient souvent sur... une hiérarchie d'héritage se rapprochant fortement du concept de "super objet" que je souhaites éviter à tout prix.

Nous pourrions faire appel aux tuple (qui sont redescendues de TR1 vers std) pair et autres "typelist" pour manipuler le "contenu" et implémenter par ailleurs "quelque chose" qui permette de visiter chaque élément, mais il faut avouer que l'écriture d'un code (qui serait pourtant correct ) proche de

Code c++ :

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

1
2
3
4
5
6
7
8
9
10
11
12
class MyClass : Visitor< Class1, Class2, Class3, Class4, Class5 >
{
    public:
        MyClass():Visitor( Class1( this ), Class2( this ),
                           Class3( this ), Class4( this ), Class5( this ) )
        {
        }
        void doSomething()
        {
            /*...*/
        }
};

serait sans doute de nature à enchanter les puristes, mais aussi (et surtout ) à... faire fuir les débutants...

Et je crains que la solution qui consisterait à conseiller la définition d'un alias de type (ou à les définir nous même) ne soit pas vraiment plus intéressante, et ce d'autant moins qu'il y a de fortes chances pour que Class1...ClassN doivent suivre le même chemin

Quelle serait donc, selon vous, la manière la plus intéressante pour arriver à "factoriser" ces aspects et donc permettre "à qui veut" de s'amuser avec les templates, tout en ménageant la facilité d'utilisation que nous souhaitons garder pour Farfelue

A ce sujet, nous devrions essayer de partir du principe que c'est au développeur de se "casser la tête" pour faciliter la vie de l'utilisateur

[méphistopheles]

Je vais sans doute ne faire que démontrer l'étendue de mon ignorance et peut être du fait que j'ai mal lu le post original (un peu long), mais j'avoue ne pas être sûr de saisir les trois concepts évoqué ci-dessus (je n'ai pas vraiment d'expérience de l'IHM).

Si le composite semble simplement décrire un objet en contenant d'autres, je ne suis pas sûr de comprendre correctement quelle fonctionnalité remplit le médiateur .Pour moi, celui-ci doit permettre à ses composants de pouvoir interagir entre eux (en les référençant) et éventuellement leur fournir une "vision globale" (placement & collision, plan (avant, arrière), destruction ...)
Par contre, je dois avouer que la notion de visiteur ne m'évoque rien d'autre que l'accès d'une classe sur une autre mais je ne vois pas en quoi un composite ou médiateur serait obligé d'être visiteur de ses éléments puisqu'il pourrait se contenter de leur fournir des méthodes renvoyant les paramètres adéquats (dans le cas du placement par exemple).
De même, il serait peut-être même envisageable que pour des fonctions telles que le placement des membres se contentent d'appeler des méthodes sur la liste des composants.

D'autre part, si il me semble possible de ne pas utiliser un unique super objet, il me semble tout de même pour des raison d'implémentations qu'on ne peut éviter d'avoir un certains nombre de classes abstraites définissant des types d'objets et dont un composant hériterais de façons composite en fonction de ses besoin. D'où ma question: jusqu'à quel point faut-il éviter les supers-objets ? L'implémentation qui me vient le plus naturellement à l'esprit serait par exemple, d'avoir une classe abstraite composite, une classe abstraite composant et un certain nombre de classes de propriétés (classe de reception de signaux, classes d'émission de signaux(template, tuplée en fonction de la cible), classe d'affichage) et un certain nombre de classe plus évoluées les combinant. Même si on n'a pas là un super objet unique, on en arrive quand même au final à créer des presque-supers-objets d'autant plus que je soupçonne le fait que la plupart des composant de base utilisable (çàd ceux pour l'utilisateur final) hériterons pour beaucoup d'objets intermédiaires tenant "presque du super objet": certes, un radio button n'aura pas à hérité d'un composite de même qu'une grille (pour organiser les objets) n'aura pas forcément besoin d'affichage (pour affichage groupé on pourrait alors faire un parcourt exhaustif des composant). Toutefois, le composants intermédiaires ont de fortes chances de présenter toutes les caractéristiques d'un super objet.


Je souhaiterais donc savoir si et si oui, en quoi ma vison est-elle erronée/biaisée/icomplète/à coté de la plaque () ?

Sinon, et si je fait un post surnuméraire ou du déjà vu/dis, merci de me donner un lien pour que je puisse compléter mes données et me mettre en délestage.

Ps: merci d'avoir lu, c'est un peu long en fait

Cordialement

[minnesota]

Salut,

Voici une synthèse de la discussion ayant conduit à l'adoption du projet Farfelue qui te permettra de mieux appréhender le projet.

Maintenant en ce qui concerne le super-objet, et l'héritage en général, c'est tout simplement évité au profit des classes de trait et de politique.