Discussion :

[Seabirds]

Bonjour et toutes et à tous,

J'ai pas mal cherché de droite et de gauche, mais je ne suis pas parvenu à trouver de réponse exacte à mon problème (sans aucun doute extrêmement classique) :

Je fabrique des objets à un moment donné, auxquels manquent certaines spécificités qui sont encore inconnues au moment de la construction de l'objet. D'après ce qu'il me semble avoir compris, ce serait une mauvaise idée de construire un objet "global" avec des attributs vides pour les remplir petit à petit. D'où mon idée de faire une chaîne d'héritage de l'objet le moins complet A (ancêtre) vers le plus complet B (dérivé), et de les promouvoir au bon moment quand l'attribut est calculable.
Le truc que je ne sais pas, c'est le où/quand/comment dire en C++ "prend l'objet A, transforme le en B en ajoutant cet attribut_là qui manquait".
C'est vrai que ça paraît élémentaire, mais je ne parviens vraiment pas à faire les bonnes requêtes. Pourriez-vous au moins me donner des mots clés, que je puisse préciser mes recherches internet ? J'ai l'impression que ça ressemble à du clonage amélioré...

Merci d'avance !
Bien cordialement,

[Edit]
Je suis tombé sur ce sujet qui à l'air de ressembler à ce que je veux... sauf que c'est en python et que j'y comprends rien :/ http://www.developpez.net/forums/d71...bjets-parents/

[prgasp77]

Aussi simplement que 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
class Coords2D
{
    double _x;
    double _y;
public:
    Coords2D(double x, double y) : _x(x), _y(y) {}
};
 
class Coords3D : public Coords2D
{
    double _z;
public:
    Coords3D(Coords2D const& base) : _x(base.x), _y(base.y) {}
    Coords3D(Coords2D const& base, double z) : _x(base.x), _y(base.y), _z(z) {}
};

J'ai éliminé de cet exemple tout élément normalement indispensable mais qui n'illustre pas mon propos. Pense à définir tes classes proprement (tous les constructeurs, destructeurs virtuel si besoin, assignation, etc.).

[Seabirds]

Merci de ta réponse !

En fait, on ne rajoute pas un attribut à un objet déjà existant, on en reconstruit littéralement un de novo, en allant piquer les attributs dans l'objet de la classe parent. C'est bien ça ?

Si oui, cela me parait un peu bizarre sur le plan conceptuel, parce que ça nous oblige à connaître exactement la composition de l'objet parent (alors qu'on s'en fiche un chouïa), et à écrire des choses qu'on ne devrait pas forcément écrire (on veut pas toucher aux attributs déjà définis, on veut juste en rajouter un).
De plus ça me semble (naïvement) couteux de reconstruire un objet "from scratch" (avec possiblement pleins d'attributs) plutôt que de juste ajouter une seule info. Parce qu'il faut dire que je compte faire cette opération sur un parcours d'arbre, avec plusieurs centaines de feuilles, parcours répété quelques dizaines de millions de fois... La POO ne propose aucun moyen de faire autrement ?

Merci de ta réponse en tout cas, je vais déjà appliquer ça dans un premier temps !

[foetus]

Alors essaye de regarder du côté des traits ou des class Policy en C++

Désolé , mais je n'arrive jamais à retenir les différences entre les 2: c'est pour cela que je n'ai pas d'explication.

Sinon, un héritage de 1 ou 2 n'est pas pénalisant .
Moi avec la VCL (C++ Builder) je me mange des héritages de 7 à 10 de profondeur (*) et cela passe [en apparence et avec 2-3 tests] crème.

*: TObject -> TPersistent -> TComponent > TControl -> TTwinControl -> TScrollingWindow -> TCustomForm -> TForm, TForm une fenêtre de base toute bête

[jo_link_noir]

Si toutes les feuilles sont du même type (comprendre, vont au final avoir les mêmes attributs), l'héritage est une mauvaise idée. On préfère effectivement initialiser tous les attributs d'une classe dans le constructeur, mais il n'y a rien de gênant à ne pas le faire. Par contre, il faut que la fin du processus de création retourne des objets valides.

Si les étapes de construction initialisent des attributs différents, tu peux les séparer en plusieurs classes et les regrouper en tant que ’attribut dans le type de la feuille (ou faire des proxy). Ainsi, il est plus facile d'initialiser juste les attributs concernés par une fonction d'initialisation/de construction.

[Bousk]

En fait, on ne rajoute pas un attribut à un objet déjà existant, on en reconstruit littéralement un de novo, en allant piquer les attributs dans l'objet de la classe parent. C'est bien ça ?

Si oui, cela me parait un peu bizarre sur le plan conceptuel, parce que ça nous oblige à connaître exactement la composition de l'objet parent (alors qu'on s'en fiche un chouïa), et à écrire des choses qu'on ne devrait pas forcément écrire (on veut pas toucher aux attributs déjà définis, on veut juste en rajouter un).

Le truc c'est que tu dis vouloir le faire en C++, et t'as pas le choix.
C'est un langage fortement typé, tu peux pas te permettre de faire n'importe quoi comme en python, comme ajouter des attributs/méthodes à une classe à la volée. Et c'est pas un mal.
De là, plusieurs solutions
- tu fais du Python
- tu adaptes ta solution au C++, et si ça te semble pas bon, c'est plus certainement ta solution qui n'est pas bonne que le langage

De plus ça me semble (naïvement) couteux de reconstruire un objet "from scratch" (avec possiblement pleins d'attributs) plutôt que de juste ajouter une seule info. Parce qu'il faut dire que je compte faire cette opération sur un parcours d'arbre, avec plusieurs centaines de feuilles, parcours répété quelques dizaines de millions de fois... La POO ne propose aucun moyen de faire autrement ?

Un objet qui stocke 3 int n'aura rien de couteux..
Une centaine de feuilles c'est ridiculement bas. Mais "quelques dizaines de millions" de parcours, ça me parait au contraire très exagéré et/ou une mauvaise idée. En tous cas ce chiffre balancé comme ça n'a pas grand sens.

Et si tu veux juste initialiser un certain type, ajouter un attribut int à une classe, on a inventé la map.

[Seabirds]

Merci à tous pour vos réponses, je vais potasser tout ça !

Mais "quelques dizaines de millions" de parcours, ça me parait au contraire très exagéré et/ou une mauvaise idée. En tous cas ce chiffre balancé comme ça n'a pas grand sens.

Et pourtant ce n'est pas exagéré, c'est une méthode statistique classique pour l'estimation de paramètres d'un modèle probabiliste, méthode qui consiste à faire des simulations massives (de l'ordre de plusieurs millions) lorsque toutes les autres méthodes inférentielles sont inopérantes. Pour ceux que ça intéresse, elle porte le doux nom de "Approximate Bayesian Computation". Et mon modèle nécessite la construction et le parcours de plusieurs dizaines d'arbres à chaque simulation, d'où le chiffre de plusieurs dizaines de millions avancé plus tôt Je voulais vous épargner cette explication

En tout cas merci encore à vous tous, je vous tiens au jus dès que j'ai réussi à pondre un truc potable !
Bien cordialement,

[prgasp77]

En gros, ce que tu souhaiterais c'est du Decorator Pattern mais avec des données plutôt que des comportement ? Je suis certain que c'est faisable. Ensuite, est-ce la meilleure solution ?