Discussion :

[fabthegreat]

Bonjour à tous (et joyeuses fêtes ),


j'ai un petit problème de conception (enfin ca ressemble à ca ).

Pour mon petit code de client chat en ligne de commande, je cherche à clairement séparer la partie interface (entree et sortie) de la partie gestion de la des communications.

Pour la petite histoire, j'utilise ncurses pour l'interface (j'ai pas trouvé de workaround en C++) et gloox pour la partie XMPP.

Du coup ce que j'aimerai faire:



INPUT -------> PARSER ------> OUTPUT

et PARSER <------> CORE

Je précise que les fleches ne représentent pas de notion d'heritage

Le PARSER traduit les commandes de l'utilisateur (venant de INPUT) et lance des actions (en autres du CORE) et affiche le résultat sur OUTPUT.
Par exemple quand je vais taper la commande /lister_contact dans INPUT, le PARSER sera en charge de reconnaitre la commande et de lancer une fonction membre de CORE pour retourner la liste des contacts à OUTPUT.

Le fait est que je n'ai pas envie que le PARSER soit complétement dépendant d'une implémentation de CORE, je n'ai donc pas envie d'initialiser PARSER avec un objet CORE.

Pour résoudre ceci j'ai pensé à faire hériter ma classe CORE de ma classe PARSER. Je pourrais donc redéfinir les fonctions membres de PARSER dans ma classe CORE.
Ca me fait juste bizarre de voir heriter une classe de l'autre alors que je les vois assez indépendantes.
On m'a aussi proposer d'utiliser des pointeurs de fonction, mais dans tous les cas déclarer un pointeur de fonction sur une fonction membre d'une classe revient à un peu trop lier ma classe et mon pointeur issu d'une autre classe.

Peut être suis-je un peu trop exigeant concernant cette fameuse indépendance entre mes classes et qu'il faut à un moment donné fournir des informations de l'une sur l'autre...

Qu'en pensez vous?

Merci à tous

[koala01]

Salut,

En fait, il n'y a absolument pas d'héritage à avoir:

Tu devrais avoir une (hiérarchie de) classe(s) pour la (les) commande(s), une classe pour le récepteur, qui envoie ce qu'il a recu vers le parser (qui transforme le texte recu en commande(s), et qui envoie la (les) commande(s) vers le corps du système qui devra les gérer.

le corps du système sera lui meme sans doute composé de plusieurs classes mise en commun pour générer un "message" qui sera transmis à ... un émetteur pour etre renvoyé vers le correspondant

Emetteur et récepteur travailleraient tous les deux avec une (hiérarchie de) classe(s) s'occupant de gérer les sockets et connexions diverses

[fabthegreat]

En fait j'ai fait un petit diagramme de ma conception...
http://lutix.org/data/Diagramme.png
En résumé: je lance une commande d'un objet Input qui envoit l'information à un objet Linker.
Ce linker la parse et soit l'envoit à un objet Output qui l'affiche à l'écran soit envoit à un objet core qui en fait quelquechose... sauf que cet objet core peut aussi (à l'écoute du serveur XMPP) envoyer une info au linker qui la relayera à l'output...
J'ai crée une classe interface

Evidemment je pourrai séparer la classe Linker en 2 objets tous les deux reliés à Output pour séparer les traitements. Mais ca m'empêcherait de résoudre un serpent qui se mord la queue et je pense qu'il faut avoir vu ça au moins une fois dans sa vie de développeur débutant.

Mes questions:
1) dans toutes ces relations que j'ai décrit, je ne sais jamais vraiment si je dois créer un objet membre de la premiere classe à l'intérieur de la seconde (du style un Linker dans un Input) ou tout simplement inclure le premier comme argument de fonction de la seconde...?
2) comment feriez vous pour relier intimement 2 classes (un peu comme Linker et Core) qui doivent communiquer entre elles dans les 2 sens? Qu'est ce qui est le plus propre?

En vous remerciant!

[3DArchi]

Salut,
J'aurais à priori inversé ICore_XMPP et Linker puisque ICore_XMPP semble être une classe abstraite et Linker une classe concrète.

1) dans toutes ces relations que j'ai décrit, je ne sais jamais vraiment si je dois créer un objet membre de la premiere classe à l'intérieur de la seconde (du style un Linker dans un Input) ou tout simplement inclure le premier comme argument de fonction de la seconde...?

Ca dépend. Si tu te retrouves à passer l'argument à chaque fonction, c'est que le lien est plus fort. Les questions à se poser sont pour savoir quel lien établir dans A avec B :
=> Que peut faire A sans B ?
=> un B peut il être partagé (simultanément ou successivement) par plusieurs A ?
=> un B doit-il être crée pour un A et détruit avec la destruction de A ?

2) comment feriez vous pour relier intimement 2 classes (un peu comme Linker et Core) qui doivent communiquer entre elles dans les 2 sens? Qu'est ce qui est le plus propre?

Ca dépend essentiellement de la sémantique des canaux de communication. Il se peut que le sens Core->Linker soit plus un DP Observer là où un Linker->Core pourrait relever d'un client/serveur (simple hypothèse de ma part dans les 2 cas). Cela ne s'implémenterait pas forcément de façon symétrique (et nécessiterait peut être de séparer les différents rôles).
Je pense qu'il faut d'abord identifier à quoi sert l'association entre les deux classes dans chaque sens.

[fabthegreat]

Ca dépend. Si tu te retrouves à passer l'argument à chaque fonction, c'est que le lien est plus fort. Les questions à se poser sont pour savoir quel lien établir dans A avec B :
=> Que peut faire A sans B ?
=> un B peut il être partagé (simultanément ou successivement) par plusieurs A ?
=> un B doit-il être crée pour un A et détruit avec la destruction de A ?


Ca dépend essentiellement de la sémantique des canaux de communication. Il se peut que le sens Core->Linker soit plus un DP Observer là où un Linker->Core pourrait relever d'un client/serveur (simple hypothèse de ma part dans les 2 cas). Cela ne s'implémenterait pas forcément de façon symétrique (et nécessiterait peut être de séparer les différents rôles).
Je pense qu'il faut d'abord identifier à quoi sert l'association entre les deux classes dans chaque sens.

Merci pour tes réponses!
Effectivement, ca ressemble un peu à ce que tu dis! ICore_XMPP envoit des signaux et Linker les recoit. Dans l'autre sens c'est + formalisé

Etant donné que je débute en C++, je me demandais si commencer par des pointeurs en tant qu'objet membre dans mes classes serait pas mal pour définir les liaisons entre les objets. Par contre, je ne peux évidemment pas les initialiser dans le constructeur à cause des interdépendances... je devrais appeler une méthode à part pour associer A à B et vice versa, non?

Sinon tu me conseilles quoi comme bibliothèque pour les signaux et les slots?

[3DArchi]

Etant donné que je débute en C++, je me demandais si commencer par des pointeurs en tant qu'objet membre dans mes classes serait pas mal pour définir les liaisons entre les objets.

En tant que débutant, tu devrais éviter d'utiliser des pointeurs nus et préférer des classes qui s'occupent de tout ça pour toi (vector, smart ptr, etc.).

Par contre, je ne peux évidemment pas les initialiser dans le constructeur à cause des interdépendances... je devrais appeler une méthode à part pour associer A à B et vice versa, non?

Ca ne me choque pas d'avoir une classe builder dédiée à la construction des différents objets et au tissage de leur relation.

Sinon tu me conseilles quoi comme bibliothèque pour les signaux et les slots?

Simple, efficace et une fois installée devenue indispensable : Boost avec Boost.Signal