Discussion :

[Seabirds]

Bonjour à toutes et à tous !

Je me débats toujours avec mes objets, et déséspère parfois d'en voir le bout, mais quitte à être pris en flagrant délit d'optimisme forcené, je dirais que "si ça ne stagne ni ne régresse, ça progresse forcément"...

J'avais implémenté une classe généraliste pour un arbre n-aire. Il se trouve que deux classes sont vouées à en dériver, la classe BayesianModel et la classe Lineage. Pour avoir de la flexibilité sur le type de données que contient l'arbre et n'implémenter les algorithmes de parcours qu'une seule fois, j'ai encapsulé les données dans chaque noeud dans un champs _data de classe "DataTypeForTree*", de laquelle dérive notamment la classe "BayesianModelData" (pour les Lineages on verra plus tard).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class KaryTree
{
    public:
        // Constructors
        KaryTree* _parent;
        KaryTree(const DataTypeForTree &data);
        KaryTree(DataTypeForTree &data, std::vector<KaryTree* > children);
        ~KaryTree() ;
 
        // Setter/Getter
        DataTypeForTree* GetData(void);
        void SetChildren (std::vector<KaryTree* > children);
        void SetParent (KaryTree* parent);
 
        // Traversal algorithms
        void SearchDeepFirst (const VisitorInterface & visitor);
        void Accept(const VisitorInterface & visitor);
 
    private :
        std::vector<KaryTree* > _children; //private because it is the core of this class
 
    protected :
        DataTypeForTree* _data; // protected because it can change in the derived classes
};

Code :

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

1
2
3
4
5
6
7
8
9
10
class BayesianModel : public KaryTree
{
    public:
        BayesianModel(const BayesianModelDataType &data);
        virtual ~BayesianModel();
        //[...]
 
    protected:
    private:
};

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
class BayesianModelDataType : public DataTypeForTree
{
    public:
        BayesianModelDataType(const IMathematicalParametrizedFunction &fun, const std::string &param);
        BayesianModelDataType(const IMathematicalParametrizedFunction &fun);
        virtual ~BayesianModelDataType();
 
    protected:
    private:
    IMathematicalParametrizedFunction _fun;
    std::string _informedParameterOfParentFunction;
};

Dans la liste d'initialisation du constructeur de BayesianModel, j'appelle le constructeur de KaryTree. Seul souci, la classe de données nécessaire n'est pas la même :

Code :

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

1
2
3
4
BayesianModel::BayesianModel(const BayesianModelDataType &data) : KaryTree(data) // lui il a besoin d'un argument const DataTypeForTree
{
    //ctor
}

Je crois qu'il y a un DataTypeForTree &rBase = cDerived à caser dans la liste d'initialisation mais
1) J'en suis pas sûr
2) Si c'est le cas, je ne sais pas comment l'écrire
3) Pourriez-vous me guider ?

Merci d'avance de votre aide !

[foetus]

Et comme cela

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class KaryTree {
public:
//  Constructors
/* ... */
    KaryTree(DataTypeForTree* data, std::vector<KaryTree* > children);
 
 
/* ... */
};
 
 
class BayesianModel : public KaryTree {
public:
    BayesianModel(BayesianModelDataType* data);
 
 
/* ... */
};

[Seabirds]

Super j'essaie ça !!!

Question de noob : j'arrête pas de lire qu'il faut éviter les pointeurs dans les interfaces, c'est pour ça que j'essayais de passer par des références. Y'a des cas où c'est vraiment nécessaire ?

Merci de ta réponse !

[Bousk]

Y'a des cas où c'est vraiment nécessaire ?

Oui, si le paramètre peut être null (NULL, nullptr).

[Seabirds]

Oui, si le paramètre peut être null (NULL, nullptr).

Bon, alors au moins pour les noeuds parents, c'est le cas. Merci bien !

Génial, ça marche !!! Merci encore de votre aide et votre patience !

[koala01]

Salut,

Il y a cependant quelque points que je voudrais mettre en avant, car j'ai l'impression que tu es parti pour avoir quelque problèmes...:

1. Ton approche est beaucoup trop orientée donnée et pas assez orientée services
2. Si le destructeur d'un de tes types dérivés est public et virtuel, c'est le destructeur du type de base'KaryTree) qui devrait l'être. L'autre solution consiste à déclarer le destructeur de ta classe de base (KaryTree ) comme étant protégé et non virtuel, mais pose certaines limitations dont il faudra que tu pèse le pour et le contre
3. Typiquement, tout ce qui est collection n'a pas sémantique d'entité. Tu peux donc envisager d'utiliser le paradigme générique, mais, a priori, l'héritage (qui reste la relation la plus forte qui puisse exister entre deux classe) n'est pas la solution si plusieurs type doivent agir "comme une collection du type" que tu as créé (en deux mots : il faut se méfier de ceux qui disent que l'héritage est une relation X EST-UN Y : ce n'est pas ** forcément ** faux mais ce n'est pas toujours juste)

Et de manière plus spécifique :

1. le noeud parent devrait -- ad minima -- être transmis directement dans le constructeur, quitte à ce qu'il soit représenté sous la forme de nullptr dans le cas du noeud racine
2. les enfants devraient pouvoir être manipulés (ajoutés, accédés, supprimés) "à l'unité" (un à un) et non uniquement "à l'ensemble"
3. Quand ils existent (et encore faut il qu'il y ait une raison pour que ce soit le cas), les accesseurs (getXXX) devraient être des fonctions constante et renvoyer des valeurs ou des références constantes
4. Si tu n'as pas de raison pour fournir un accesseur, tu n'as aucune raison pour fournir un mutateur (setXXX) et, meme si la présence d'un accesseur est cohérente, il y a de très fortes chances pour que celle du mutateur correspondant ne le soit pas

Toutes ces remarques mériteraient chacune un "long discours dont j'ai le secret", ce qui aurait (cela ne m'arrive pas souvent) sans doute pour résultat de faire que le serveur refuse ma réponse "parce qu'excédant 65 536 caractères". Mais je suis certain que tous les aspects évoqués ici ont déjà été débattus en long, en large et en travers sur le forum (et que j'ai régulièrement pris part à la discussion).

Je vais donc -- pour une fois -- te laisser cogiter quelque peu ces réponses "laminaires", mais n'hésite pas à me demander d'avantage de précision sur l'un ou l'autre point précis

[ternel]

Concernant les mutateurs, il y a toujours la très longue discussion Quand les mutateurs nous mentent.
C'est un poil long à lire, mais ca explique bien à la fois les différents points de vue, et le pourquoi du conseil de Koala01

[Seabirds]

Pfiouu merci à vous deux pour ces éminents conseils.

J'avoue sans honte avoir lâché la discussion (super intéressante) sur les mutateurs à la fin de la première page, j'y reviendrai plus tard.

Ton approche est beaucoup trop orientée donnée et pas assez orientée services

mais, a priori, l'héritage (qui reste la relation la plus forte qui puisse exister entre deux classe) n'est pas la solution si plusieurs type doivent agir "comme une collection du type"

Si je comprend bien, plutôt que de dériver des classes de collections, je ferais mieux de concevoir une classe généraliste (KaryTree) qui fournit l'ensemble des services qu'on est en droit d'attendre d'un arbre n-aire (tout pour le construire/déconstruire/modifier/parcourir...), et j'utilise KaryTree et ses services pour encapsuler des données de type différents (BayesianModel, Lineages), sur lesquelles je peux effecteur des traitements type-spécifique grâce à un patron Visiteur ?

Est-ce que j'ai bien compris ?

Si oui, j'y vois des avantages :
- pas besoin de ré-implémenter en parallele un nouveau type de collection et son type de données correspondant
- et tous les services sont centralisés, on évite de ré-implémenter les mêmes services dans deux classes dérivées.

Par contre, au niveau conceptuel, quand je vais demander "mais c'est quoi cet objet", il me dira que c'est un KaryTree, alors que dans ma tête c'est très différent si l'objet représente une lignée ou un réseau bayésien. J'imagine que je loupe une subtilité ?

[ternel]

L'idée, ca serait plus de définir un KaryTree comme un type utilitaire (exactement comme map ou vector), et de ne pas en hériter du tout. Tes classes utiles en contiennent un, mais c'est un détail.

[Seabirds]

Super merci beaucoup !

Bon alors maintenant BayesianModel est une classe contenant un private de type KaryTree encapsulant des données de type BayesianModelDataType.

Code :

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

1
2
3
4
5
6
7
8
class BayesianModel
{
    public: 
         //....
 
    private:
        KaryTree m_modelHierarchy;
};

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class KaryTree : public IVisitable
{
    public:
        // Constructors
        KaryTree(DataTypeForTree* data);
        KaryTree(DataTypeForTree* data, std::vector<KaryTree* > children);
        ~KaryTree() ;
 
        void AddAChild(KaryTree * child);
        void AddChildren(std::vector<KaryTree* > &children);
        void DeleteAndRemoveChild(KaryTree * child);
 
        // Traversal algorithms
        void Accept(IVisitor & visitor);
        void SearchDeepFirst (IVisitor & visitor);
 
        // Data
        KaryTree* m_parent;
 
 
    private :
        std::vector<KaryTree* > m_children;
        DataTypeForTree* m_data;
};

Un problème résolu, dix de soulevés : j'ai besoin d'arpenter l'arbre multinaire KaryTree notamment au moment de sa construction. En effet, je pars de la racine, et j'ajoute progressivement des noeuds, jusqu'à ce que les feuilles remplissent une condition (l'information étant cachée dans m_data de type BayesianModelDataType). Pour construire ça progressivement, j'ai voulu faire un Visitor qui donne accès à la première feuille de l'arbre rencontrée ne remplissant pas la condition. Seul souci : l'information est cachée dans le private de KaryTree, donc je n'arrivais pas à y accéder avec le Visitor.

Ici (http://www.codeproject.com/Articles/...nplusExplained) j'ai trouvé ça :

Access to Private Members
There’s another issue when the visitors need access to private data of the visitables.
To stick with the visitor pattern, you may be force to make this data public, even though it’s not supposed to be public, thereby breaking the principle of information hiding.

Je vais faire comme ça, mais c'est vrai-de-vrai ce qu'ils disent ? Pas moyen de faire autrement ?

Merci d'avance de votre réponse !

[EDIT]
J'ai aussi trouvé ça donc mes illusions commencent à se dissiper...

Visitor's approach assumes that the ConcreteElement interface is
powerful enough to let visitors do their job. As a result, the pattern
often forces you to provide public operations that access an element's
internal state, which may compromise its encapsulation.

C'est en général révélateur d'un souci de conception ou bien on y est souvent confronté ?

[koala01]

Heu, une petite question...

Les conditions qui font qu'un noeud peut ou ne peut pas avoir d'enfant, si je ne me trompes (mais dis le alors ), elle seront toujours identiques pour un type de donnée particulier, non

Comme je suis pas sur que cette question soit bien compréhensible, essayons autrement : si je décide de mettre des BayesianModelDataType -- faudrait vraiment trouver un terme plus clair pour ce nom de type -- dans ta collection (étant entendu que je ne mettrai alors aucune donnée d'un type différent), les conditions pour qu'un noeud puisse accepter d'avoir un (ou des) enfants seront toujours les mêmes, dans le sens où si tu as un noeud présentant une valeur de XXX qui ne peut pas avoir d'enfant, un autre noeud présentant la même valeur de XXX ne pourra pas non plus avoir d'enfants. Me trompes-je

Si j'ai bien raison de penser cela (et le contraire m'étonnerait, autrement nous aurions surement de problèmes de reproductibilité), il doit être possible d'exprimer la logique qui te permet de décider si un noeud donné peut avoir des enfants ou non sous la forme d'une fonction.

Dés lors, pourquoi ne pas mettre cette logique dans une fonction membre (de BayesianModelDataType ) -- que tu nommerais mettons canHaveChildren et qui renverrait true si l'élément courant peut avoir des enfants et false s'il ne peut pas

Si tu veilles à ce que cette fonction est publique, tu n'auras absolument aucun problème pour déterminer, à l'intérieur de ton arbre, si un noeud peut ou non avoir des enfants, et tu n'auras même pas à t'inquiéter de la visibilité accordées aux différentes données qui permettent d'obtenir la réponse

Une autre solution pourrait consister à paramétrer ta classe KaryTree avec une fonction qui aura pour but de nous dire si oui ou non un noeud peut avoir un enfant. Cela apporterait bien de la souplesse au système, mais... as-tu les connaissances suffisantes en C++ pour le faire

[Seabirds]

Merci mille fois de ta réponse !

mais... as-tu les connaissances suffisantes en C++ pour le faire

Question réthorique...

dans le sens où si tu as un noeud présentant une valeur de XXX qui ne peut pas avoir d'enfant, un autre noeud présentant la même valeur de XXX ne pourra pas non plus avoir d'enfants. Me trompes-je

La phrase est logiquement exacte, mais je ne crois pas que la proposition soit complète.
Si un noeud encapsule dans ses données un objet d'un certain type, alors il ne peut pas avoir d'enfants. Deux objets de ce même type peuvent varier en valeur (j'entends varier dans leur paramétrage), mais ils détermineront quand même la condition "pas d'enfants"

Dés lors, pourquoi ne pas mettre cette logique dans une fonction membre (de BayesianModelDataType ) -- que tu nommerais mettons canHaveChildren et qui renverrait true si l'élément courant peut avoir des enfants et false s'il ne peut pas

C'est ce que j'avais fait, en créant dans la classe BayesianModelDataType (promis je changerai le nom) la fonction "isTheMathematicalFunctionADiracDistribution", qui renvoie true (pas d'enfants) ou false (enfants).
Je n'avais pas envie de la transférer à la classe KaryTree parce que telle quelle cette fonction était spécifique du type de données encapsulées. C'est donc là qu'à défaut d'être un crac du C++ on se la pète en citant Spinoza "La plupart des erreurs consistent en cela seul que nous ne donnons pas correctement leurs noms aux choses", et qu'on essaie de coder la fonction "CanHaveChildren" qui est plus générale.

Merci encore !

[ternel]

en fait, ca aurait été bien que le DataNode (et donc concrêtement, BayesianModelDataType) possède bien une fonction canHaveChild (une considération liée à sa nature d'élément de l'arbre).

Cette fonction pourrait renvoyer, dans le cas précis du BayesianModelDataType, la valeur de isTheMathematicalFunctionADiracDistribution.
(Dont le nom indique que c'est clairement une propriété de la nature Mathématisable du BayesianModelDataType.)

Au passage, aucune fonction mathématique n'est une distribution de Dirac.
Précisément par la définition de fonction et de distribution

[Seabirds]

Merci l'eternel !

en fait, ca aurait été bien que le DataNode (et donc concrêtement, BayesianModelDataType) possède bien une fonction canHaveChild (une considération liée à sa nature d'élément de l'arbre).

Cette fonction pourrait renvoyer, dans le cas précis du BayesianModelDataType, la valeur de isTheMathematicalFunctionADiracDistribution.
(Dont le nom indique que c'est clairement une propriété de la nature Mathématisable du BayesianModelDataType.)

Bon bah ça finit par rentrer: c'était exactement ce que j'étais en train de faire

Au passage, aucune fonction mathématique n'est une distribution de Dirac.
Précisément par la définition de fonction et de distribution

Ahaha oui, j'avais bien lu que c'était un abus de langage, que la fonction de Dirac n'était à proprement parler pas une fonction, mais plutôt qu'elle "étendait le concept de fonction". Bon, j'ai eu beau lire ça, je suis pas mathématicien, donc les subitlités m'échappent, mais tout ce que j'avais envie d'y faire c'est de pouvoir "échantillonner" dedans de la même manière qu'on pourrait échantillonner dans d'autres distributions :
Cf mon pote wikipedia :

Une densité de probabilité, par exemple celle de la loi normale, est représentée par une courbe qui enferme une aire égale à 1. Si on fait tendre sa variance vers 0, on obtient à la limite un delta (dirac) qui représente la densité de probabilité d'une variable certaine avec la probabilité 1

Ca me semblait bien coller avec le cadre du bayésien où on modélise les incertitudes...

[ternel]

La distribution de Dirac se défini comme la fonction valant 0 (sur R privé de 0), et complétée en 0 par une valeur telle que l'intégrale (elle aussi étendue en étant malin) sur R vaille 1.

En pratique, la distribution de Dirac vaut limite de 1/x pour x tendant vers 0, c'est à dire l'infini.
C'est en cela que ce n'est pas une fonction: l'infini n'appartient pas aux valeurs tolérables des fonctions.

[Seabirds]

Merci pour ces précisions

Plus ça prend forme, plus je pense de toute façon faire sauter cette classe Dirac : elle semble correspondre à ce qui est appelé vulgairement ici "une solution maladroitement over-engineered"

Pour ce que ça vaut, ça fonctionne plus ou moins, donc je clos le sujet. Mais merci encore de toutes vos suggestions