Promotion d'objet et attribut manquant

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/

Aussi simplement que cela :

Code:

---

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.).

Merci de ta réponse ! :D

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 ! :)

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

Désolé :wow:, 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 :mrgreen:.
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 :mrgreen:

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.

Citation:

---

Envoyé par Seabirds

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

Citation:

---

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.

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

Citation:

---

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,

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 ?

Des Design Pattern de création d'objet, il y a en pas mal, https://en.wikipedia.org/wiki/Creational_pattern.

En fait je penses que le problème est d'essayer de conceptualiser cela avec l'héritage, plutôt qu'avec des compositions. Peut-être qu'avec un conteneur d'une classe "Propriete" ? Ensuite a toi de spécialiser cette classe selon tes besoins ? En terme de service, cela me parait plus difficile à concevoir, mais ça ouvrirai plus de flexibilité...

Ce que tu veux, Python, Js, ou encore C# le permettent, en C++, étendre une classe à la volée n'est pas possible, à ma connaissance.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

class Parameter {   }   class CoordParameter ; public Parameter { double dim;   public : Coord(double d); }   <typename Label> class Parametrable { std:map<Label, Parameter> proprietes; }   class Coords : public Parametrable<string> { public: addCoord(string axe, double d) { proprietes[axe] = new Coord(d); } };

---

Bon c'est un brouillon qui ne compilera pas du tout et qui nécessite d'être améliorer mais c'est juste pour donner une idée

A noter quand même que les différents types en jeu n'ont pas forcément de lien (et donc pas forcément besoin d'héritage). En JS / Python / autres c'est possible de rajouter un attribut à un objet (mais on change son type)

Code:

---

1 2 3 4 5 6

var obj = { x: 42, y: 12 };   obj["z"] = 45; // on ajoute un "membre" z

---

En C++ c'est pas possible, mais il y à plusieurs approches:
Dans certains cas une std::map fait le boulot (en considérant les couples clefs / valeurs comme des attributs d'un objet -> c'est probablement le plus proche du fonctionnement du JS, mais niveau perf c'est pas la joie en C++).
Sinon comme @prgasp77 et les autres le disent, tu peux créer un nouvel objet avec le type correct (mais pas forcément besoin d'héritage; Coords3D qui hérite de Coords2D me semble être une hérésie par exemple).
Tu peux aussi utiliser un seul objet avec un membre non initialisé (mais généralement ça viole le principe qui dit qu'un objet est dans un état valide après que le ctor ait fait son boulot).

Citation:

---

Envoyé par Iradrille

Sinon comme @prgasp77 et les autres le disent, tu peux créer un nouvel objet avec le type correct (mais pas forcément besoin d'héritage; Coords3D qui hérite de Coords2D me semble être une hérésie par exemple).

---

Oui :plusser:, c'est même plus qu'une hérésie, c'est un exemple de ce qu'il ne faut pas faire à mon sens.

Citation:

---

Envoyé par Iradrille

Tu peux aussi utiliser un seul objet avec un membre non initialisé (mais généralement ça viole le principe qui dit qu'un objet est dans un état valide après que le ctor ait fait son boulot).

---

Une monade Maybe est, à mon sens, la meilleure solution.

Ok c'est noté pour toutes les solutions que vous envisagez, et je vous remercie de l'avalanche d'informations que vous m'offrez. Je suis en train de faire le tour des docs ;)

L'idée de l'héritage, c'était de pouvoir conditionner certains traitements sur un arbre en fonction du type des données encapsulées dans chaque node. En effet les états des données peuvent tout à fait être valides pour certains traitements mais invalides pour d'autres, et je ne souhaitais pas devoir tester à chaque fois si l'attribut existe ou n'existe pas... J'avais cru comprendre que quand on passe son temps à tester l'existence d'un attribut c'est qu'on avait loupé un héritage (mais j'ai certainement over-simplifié les message ^^")...
Donc dans un premier temps je vais rester sur l'option de laisser l'attribut non-défini et le définir au moment opportun comme le disait Iradrille, (et sans doute m'essayer à la monade Maybe comme proposé par prgasp77) :)
Si cette première solution me pose des soucis conséquents en terme d'héritage, je reconstruirai intégralement l'objet dans une autre classe comme proposé par prgasp77.
Et si cette deuxième solution s'avère limitante au niveau du temps de calcul, alors je m'intéresserai aux autres solutions proposées qui ont l'air fort intéressantes (traits, policy ...)

Merci encore pour votre concours,
Seabirds