Discussion :

[robux]

bonjour à tous,
On va bousculer un peu la matière grise voilà j'ai un petit soucis assez interessant.

J'ai des features "F" à attribuer à des classes "C" que je peux vous representer avec un tableau :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
- - |  C1     |  C2    | C3
-------------------------------
F1  |  X      | X       | 
-------------------------------
F2  |          | X       | X
-------------------------------
F3  |          | X       | X
-------------------------------
F4  |          |          | X
-------------------------------

Je pourrais implementer les classe feature et faire des héritages multiples pour obtenir des classes C mais je ne le souhaite pas.

Je pourrais faire un enum{ ID_C1, Id_C2,...}; puis faire un "switch case" qui instancie la bonne classe C dérivée d'une classe C' plus fondamentale mais je ne le souhaite pas.

ça m'avait l'air d'un petit problème d'algo rapide mais finalement je crois que si on renonce au multihéritage (trop compliqué si le tableau grossi) ou à écrire toutes les fonctionnalités dans une seule classe (code beaucoup trop trop redondant) bah ça devient pratiquement impossible de l'exprimé simplement...

Finalement, Je cherche en gros un algorithme d'attribution avec mes classes F codées indépendamment pour pouvoir instantcier la bonne classe C

je me trompe???

Merci

Robux!

[Florian Goo]

Bonjour,

Quand tu parles d'objets, tu parles plutôt de classes, non ?
Quand tu parles de features, tu penses par exemple à des fonctions membres présentes ou non dans chacune de tes classes ?

C'est ça ?

[robux]

Salut Flo

quand je parle d'Objet je parle effectivment de classe le quiproquo est trop dérangeant je vais modifié ça et quand je parle de feature je parle exactement de methode présente ou pas dans les classes O, c'est bien ça.

@ plus

[Florian Goo]

Mon cher roro ,

Je te propose d'utiliser des interfaces pour réaliser ta solution.

Ensuite, afin de ne pas avoir de duplication de code, la technique que j'emploie dans ces cas-là est la suivante. Par exemple, tu veux ajouter une fonction membre «reverse()» à certaines classes. Tu vas alors écrire :
- une classe nommée «reversable», qui sera ton interface
- une classe nommée «reversable_impl», qui va implémenter une fonction member «reverse()»
- la classe où tu veux ajouter cette fonctionnalité de réversion, qui va hériter de l'interface «reversable» et avoir une variable membre «reversable_impl» :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class trucmuche : public reversable
{
    public:
        void reverse
        {
            reversable_impl_.reverse();
        }
    private:
        reversable_impl reversable_impl_;
};

Et si reversable_impl a besoin d'infos sur trucmuche pour implémenter reverse(), tu les lui envoie à la construction.

Une sorte de design pattern strategy, en quelque sorte.

[robux]

hello merci pour ta réponse,

Tu vas alors écrire :
- une classe nommée « reversable », qui sera ton interface
- une classe nommée « reversable_impl », qui va implémenter une fonction member « reverse() »
- la classe où tu veux ajouter cette fonctionnalité de réversion, qui va hériter de l'interface « reversable » et avoir une variable membre « reversable_impl » :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
class trucmuche : public reversable
{
    public:
        void reverse
        {
            reversable_impl_.reverse();
        }
    private:
        reversable_impl reversable_impl_;
};

je résume :
reversable_impl_ est une de mes classe feature
trucmuche ma classe qui cherche ses features
et reverse l'interface.

Et si reversable_impl a besoin d'infos sur trucmuche pour implémenter reverse(), tu les lui envoie à la construction.

ok je te suivais pour la variable membre mais il ne faut pas que le constructeur des classes feature intègre des information sur les classe qui cherchent leur feature nan?

Ceci étant je ne penche pas que je me retrouverai dans ce cas dans la mesure ou pour implementer reverse je n'auraios pas besoin d'infos sur trucmuche.

Une sorte de design pattern strategy, en quelque sorte.

thanks je ne connaissais pas ce pattern j'y cours!

Robux

[Florian Goo]

je résume :
reversable_impl_ est une de mes classe feature
trucmuche ma classe qui cherche ses features
et reverse l'interface.

L'interface, c'est reversable !
reverse(), c'est la fonction membre que tu veux implémenter.
reversable_impl est une classe qui implémente la fonction membre reverse (et reversable_impl_, avec le underscore, est une instance de la classe reversable_impl… un objet, quoi).
trucmuche c'est une classe qui implémente la fonction membre reverse() grâce à l'objet reversable_impl_ de type reversable_impl.

Si tu veux permettre à une autre classe d'implémenter reverse(), il suffira de lui ajouter une variable membre de type reversable_impl.

ok je te suivais pour la variable membre mais il ne faut pas que le constructeur des classes feature intègre des information sur les classe qui cherchent leur feature nan?

J'ai rien compris

[robux]

L'interface, c'est reversable !
reverse(), c'est la fonction membre que tu veux implémenter.
reversable_impl est une classe qui implémente la fonction membre reverse (et reversable_impl_, avec le underscore, est une instance de la classe reversable_impl… un objet, quoi).
trucmuche c'est une classe qui implémente la fonction membre reverse() grâce à l'objet reversable_impl_ de type reversable_impl.

Si tu veux permettre à une autre classe d'implémenter reverse(), il suffira de lui ajouter une variable membre de type reversable_impl.

je prenais juste ton modèle avec tes mots pour l'appliquer au mien, comme tu me parlais avec tes outils je ne voyais pas qui jouaient le rôle des features et qui jouaient le rôle des classes. désolé

Et si reversable_impl a besoin d'infos sur trucmuche pour implémenter reverse(), tu les lui envoie à la construction.[]

Désole si je n'étais pas clair. je disais : je concevais de mettre un membre dans ma classe mais pas des information de trucmuche dans la classe reversable_imple car les feature ne doivent pas avoir des info sur les classes qui ont des feature. les feature ont pour vocation d'être des feature.

Robux

[Alp]

Sauf que si tu connais la features & compagnie à la compilation, tu peux t'appuyer sur les classes de traits et de politiques (surtout de politiques).

Ce que tu veux faire ressemble un peu à la programmation générative, tu devrais faire des recherches là-dessus

[Florian Goo]

Parce qu'en fait une politique c'est une sorte de stratégie, mais statique ?
Si oui, va falloir que je regarde ça d'un peu plus près.

[Alp]

Parce qu'en fait une politique c'est une sorte de stratégie, mais statique ?
Si oui, va falloir que je regarde ça d'un peu plus près.

C'est exactement le principe !

Je le précise d'ailleurs dans mon article je crois.

Les politiques vous rappellent peut-être le design pattern Strategy, car en réalité c'est ce à quoi elles correspondent.

[Florian Goo]

Diantre, elle m'a échappée cette petite phrase… pourtant je l'ai lu, ton article !
Merci Alp, je vais relire ça plus assidûment

[robux]

Merci @ vous je vais regarder tous ça de plus près!

[Jean-Marc.Bourguet]

Stategy
...
Also Known As

Policy

...