Discussion :

[Lintel-oo]

Bonjour à tous,

J'ai actuellement besoin d'une classe utilisant un design clone mais le problème est que la classe en nécessitant est une classe "double" template (typename T, typename U).

Je ne peux donc pas utiliser (dans ma classe)

Code :

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

virtual std::auto_ptr<T> Clone() const =0;

puisque la classe est double template.

Ma question est simple : comment puis-je faire ?

Si vous voulez de plus amples explications, notamment sur cette fameuse classe ou si vous voulez savoir quelles sont les raisons qui me poussent à utiliser ce design, n'hésitez pas !

[Flob90]

Bonjour,

Je ne comprends pas trop ta question. Tu parles bien de ça : http://cpp.developpez.com/faq/cpp/?p...es#CLASS_clone ?

Ce qu'on retourne c'est un pointeur sur un objet du type de la classe, si la classe est template alors on retourne un pointeur du type de la classe avec les même paramètres template (il n'y a pas besoin de les marquer, ils sont "automatique" au sein de la classe).

[Lintel-oo]

Effectivement je ne sais pas pourquoi je pensais que c'était impossible

Sujet somme toute résolu bien qu'assez inutile

Merci à toi

Edit : en fait j'ai quand même un probpème . Le code compile mais les objets ne sont pas du bon type : dans ma classe mère :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
template <typename T, typename U>
class Curve
{
    public:
        [...]
        virtual ~Curve()
        {}
 
        virtual Curve* Clone() const = 0;
        [...]
};

et dans une des classes fille :

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
template <typename T, typename U>
class PolynominalCurve3rdDegree : public Curve<T,U>
{
    public:
        [...]
        ~PolynominalCurve3rdDegree(){}
 
        PolynominalCurve3rdDegree* Clone() const;
        [...]
};
 
...
 
template <typename T, typename U>
PolynominalCurve3rdDegree<T,U>* PolynominalCurve3rdDegree<T,U>::Clone() const
{
    return new PolynominalCurve3rdDegree (*this);
}

Ainsi, lorsque je déclare :

Code :

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

1
2
Curve<int, double> *B = new PolynominalCurve3rdDegree<int,double>(8,6,5,2,7,9);
Curve<int, double> *A = B->Clone();

A n'est pas une PolynominalCurve3rdDegree<int,double> car je ne peux pas accéder aux fonctions membres propres à cette classe et la taille de (*A) est la même que celle de (*B) et la même que celle d'un objet de type Curve<int,double>, et non celle d'un objet de type PolynominalCurve3rdDegree<int,double>.

Me suis-je trompé quelque part dans le design ? N'ai-je pas bien compris celui-ci ?

Enfin je verrai cela demain je commence à fatiguer

[dragonjoker59]

Effectivement, tu utilises la fonction Clone de Curve qui te retourne une Curve, et que tu stockes dans un pointeur sur Curve.
Il faut donc que tu fasses un static_cast vers PolynomialCurve3rdDegree pour accéder aux fonctions de cette classe.

[Lintel-oo]

Effectivement, merci pour cette réponse claire

Sujet résolu

[koala01]

Salut,

Soit, toutefois, attentif au fait que si tu as besoin de transtyper ton Curve<int , double> * en PolynominalCurve3rdDegree<int, double> *, c'est, peut etre, que tu es confronté à un problème de conception dans le sens où tu as été "assez bête" que pour... perdre le fait que tu travaillais avec un PolynominalCurve3rdDegree

Peut etre devrais tu envisager la mise en place d'un pattern de type "visiteur" (ou similaire) qui te donnerait l'occasion de récupérer un PolynominalCurve3rdDegree<int, double>

En outre, on peut toujours se poser la question de l'opportunité réelle de maintenir dans une même collection des objets dont le type réel hérite de Curve<int, double> mais qui ne sont pas tous de type PolynominalCurve3rdDegree<int, double> ...

Mais ca, cela dépend de ton projet et je ne m'avancerai pas sur ce point

Enfin, il serait peut etre intéressant de s'intéresser pré / post conditions et aux invariants de Curve et de PolynominalCurve3rdDegree, car je ne suis pas persuadé du tout (sans rien savoir de ton projet, encore une fois) qu'il soit effectivement opportun d'avoir un héritage dans le sens où les pré / post conditions et les invariants *risquent* de violer le principe de substitution de Liskov (un peu comme le ferait une liste triée héritant de liste)

[Lintel-oo]

Effectivement après quelques réflexions je me suis aperçu qu'un "simple" héritage avec virtualité suffisait.

Donc plus besoin de connaître le type exact de courbe qu'on manipule, notamment dans le cas de courbe dérivée, pourvu qu'on connaisse son tableau de signe, commun à tous les éléments de la "famille"

Merci pour ta réponse

[koala01]

Pas de problème...

As tu, cependant, réfléchi un peu aux pré et post conditions de tes deux types de Curve

Pour rappel, pour que LSP soit respecté,

1. Les préconditions ne peuvent pas être renforcées dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse.
2. Les postconditions ne peuvent pas être affaiblies dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.

[Lintel-oo]

A vrai dire je n'avais jamais entendu parler depuis hier de pré, post condition et d'invariants

En fait, j'ai du mal à saisir exactement le concept, pourrais tu me donner un bref exemple afin que je comprenne mieux ? (enfin ça c'est assez fénéant je vais déjà voir sur internet )

[ternel]

exemple théorique de la déclaration de la fonction sqrt:

Code :

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

double sqrt(double d);

préconditions:

• explicite: sqrt prend un unique argument, d, qui est un double
• documentée: d doit être positif ou nul

Les préconditions sont normalement exprimables avec le verbe requérir
postconditions:

• explicite: la valeur de retour est un double
• documentée: la valeur de retour est la racine carrée de l'entrée
• mathématique: la valeur de retour est positive
• documentée: en cas de violation des préconditions, ... (je ne sais plus, -1 je crois)

Pour les invariants, c'est plus en rapport avec un objet (classe ou primitif)
La définition d'un invariant est "une propriété qui est vraie à tout instant".
En général, on définit un invariant dit observable: "une propriété vraie à chaque fois qu'on l'observe."

On attend d'un int qu'il garde sa valeur tant qu'il n'est pas affecté.

Une liste ordonnée garantie qu'à tout instant (hormis pendant l'execution d'une de ses méthodes), le tri est respecté.

[koala01]

En fait, préconditions, postconditions et invariants sont des termes utilisés en "programmation par contrat".

Le principe est, en (très) gros (et horriblement simplifié), de dire "donnes moi ce dont j'ai besoin tu obtiendras ce que tu attends, car, si tu ne me donnes pas ce dont j'ai besoin, je ne garanti absolument pas le résultat que tu obtiendras"

Les préconditions, ce n'est qu'un ensemble de conditions qui doivent doivent être respectées avant même le début du traitement car, autrement, il est clair que le traitement n'ira jamais jusqu'au bout.

Prenons l'exemple de l'opérateur [] qui permet de récupérer un élément par l'indice auquel il se trouve dans un tableau.

De manière générale, pour obtenir un résultat cohérent, il faut que l'indice soit "valide", ce qui peut se traduire par deux préconditions :

• l'indice doit être plus grand ou égal à 0
• l'indice doit être plus petit que le nombre d'éléments contenus dans le tableau

car, si ces deux conditions ne sont pas respectées, tu obtiendras quelque chose qui, tôt ou tard, te "pètera à la figure"

Un autre exemple pourrait porter sur les noms de fichier:

Il y a des caractères (ou des suites de caractères) qui ne peuvent en aucun cas être utilisés dans un nom de fichier, parce qu'ils représentent "quelque chose" pour le système.

Si tu essayes d'ouvrir un fichier dont le nom contient l'un de ces caractères (ou de ces suites de caractères), que ce soit en lecture ou en écriture, il est clair que l'ouverture échouera.

Tu peux donc créer une fonction qui s'assure que la chaine de caractères pressentie pour représenter un nom de fichier est bel et bien exempte de ces (suites de) caractères interdit(e)s et que cela correspond donc à un nom de fichier "valide".

Cela ne veut absolument pas dire que le fichier existe ni même (s'il existe) qu'il pourra être ouvert!!!

Cela voudra "juste" dire que, si tu veux utiliser cette chaines de caractères comme nom de fichier et qu'il n'y aura a priori pas de problème, pour autant que les autres conditions (existence du fichier, droits d'accès, absence de "lock" sur le fichier, ...) sont remplies.

Par contre, si la condition "absence de (suites de) caractères interdits" n'est pas remplies, cela ne sert strictement à rien d'essayer d'ouvrir un fichier avec le nom donné et pourrait même avoir de très fâcheuses conséquences

Les postconditions sont un ensemble de conditions qui doivent être respectées après le traitement.

Par exemple, si tu veux lire une série de données dans un fichier, tu est en droit de t'attendre à ce que les données que tu récupères après la lecture correspondent à ce qu'elles étaient au moment de l'écriture car, si ce n'est pas le cas, c'est "qu'il y a un os"

Les invariants sont enfin des conditions qui doivent être valide avant le traitement et encore être valides après le traitement.

Par exemple, on apprend en primaire qu'un carré a quatre cotés égaux et des diagonales égales et perpendiculaires.

Si tu effectues un traitement sur un carré, il est carré (et doit donc avoir quatre cotés égaux et des diagonales égales et perpendiculaires) avant le traitement et tu t'attends à ce qu'il soit encore carré (et qu'il ait donc encore quatre cotés égaux et des diagonales égales et perpendiculaires) après le traitement.

Si ces conditions ne sont pas respectées, tu pourra appeler, selon le cas, le résultat rectangle, losange, parallélogramme ou meme trapèze, mais, en tout état de cause, ce ne sera pas un carré

[Lintel-oo]

Merci pour cette explication et cet exemple

Par contre j'ai du mal à comprendre certains points :

@koala :

Les préconditions ne peuvent pas être renforcées dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des préconditions plus fortes que celles de sa superclasse.
Les postconditions ne peuvent pas être affaiblies dans une sous-classe. Cela signifie que vous ne pouvez pas avoir une sous-classe avec des postconditions plus faibles que celles de sa superclasse.

Imaginons j'ai ma classe Curve de base, qui ne définit aucun comportement mais contient juste un intervalle de définition à assigner -> aucune précondition ou postcondition

Maintenant imaginons une classe RacineCurve, héritant de Curve. Lorsqu'on accède à la méthode, héritée virtuellement de la classe mère, permettant de trouver l'image d'un point d’abscisse x, il faut vérifier que cette abscisse soit positive -> précondition.

Donc la la précondition dans la classe fille est plus forte que celle dans la classe mère -> design LSP non respecté ?

Ou sont les erreurs ? Comment résoudre ce problème, j'ai un peu de mal à saisir

[Flob90]

Dans ce cas là ca veut dire que RacineCurve ne devrait pas hériter publiquement de Curve. L'héritage publique représente une relation IS-A, donc, en particulier, tu dois pouvoir utiliser une objet de type fille où est attendu un objet de type mère. Or avec ton renforcement de pré-condition, ce n'est pas possible : un traitement sur un RacineCurve nécessite des précautions supplémentaire par rapport au traitement d'un Curve.

[Lintel-oo]

D'accord mais dans ce cas comment faire puisque là une RacineCurve est bien une Curve, sans que l'inverse soit vrai.

De plus une SinCurve, une CosCurve et une PolynominalCurve sont bien des Curves elles aussi donc je ne comprends pas pourquoi un héritage public n'est pas approprié !

Je conçois tout à fait que le fait de rajouter une précondition brise le modèle cependant, la classe curve dispose d'un intervalle de définition permettant de régler ce problème puisque celui-ci est propre à chaque type de Curve, défini par l'utilisateur et certaines contraintes propres au type de Curve.

Comment faire pour éviter de ne pas respecter le design LSP, sachant que je pensais réellement avoir fait quelque chose de logique ?

[Bousk]

Tout ceci me fait beaucoup penser au carré qui hérite de rectangle.

Peut-être avec des politics ?

[Flob90]

La notion de "être quelque chose" est très subjective. Pour la rendre non subjective il faut la définir selon le contexte, dans le cas du LSP, ce "être quelque chose" se traduit, entre autre, par ce qu'à énoncé koala01 (on pourrait aussi le traduire formellement comme c'est le cas dans l'énoncé du principe par son auteur).

Par chance il se trouve que cette définition donne souvent le même résultat que l'utilisation d'une idée intuitive et subjective du "être quelque chose". C'est souvent vrai, mais pas toujours. En particulier dès que l'on considère des objets mathématiques (les exemples sont nombreux).

Donc non, un RacineCurve n'est pas une Curve (pas dans ton design actuel).

NB: Pour la suite je ne fais que supposer, je ne connais pas tes besoins exactes.

On pourrait voir le type Curve comme une réprésentation d'un lien entre deux espaces (en généralisant on tombe sur la notion d'application). Ainsi son interface pourrait offrir :
-> Connaitre les espaces de départ et d'arriver
-> Donner l'espace image d'un sous-espace de l'espace de départ

La seconde est interessante, on peut lui donner comme précondition d'avoir un espace d'entrée qui est bien sous-espace de l'espace de départ.

Ensuite il faut déterminer la nature des différents points de variation, savoir ce qui doit évoluer à l'execution et ce qui sera déterminé à la compilation. A partir de ca tu pourras déterminer ce qui doit être des templates (ce qui est déterminé à la compilation) et ce qui doit être des données membres (ce qui évolue à l'execution).

La dernière étape sera d'écrire les algorithmes qui vont bien, mais si tu as bien déterminé ce qui est données membres de ce qui est template, alors ca devrait aller assez bien.

Personnelement, je ne suis pas convaincu qu'il y est nécessairement besoin d'héritage ici.

[Lintel-oo]

@Bousk :
carré qui hérite de rectangle

Oui c'est exactement le même problème ^^

@Flob90 : tout cela me semble bien compliqué je ne saisis pas bien ce concept de double espace relié par la classe Curve

Edit : après relecture je comprends mieux ton idée, même si je dois admettre que je vois mal où placer les spécificités de chaque type de courbe sans héritage, à moins d'utiliser des templates ?

[gbdivers]

En fait, préconditions, postconditions et invariants sont des termes utilisés en "programmation par contrat".

J'en profite pour rappeler qu'il existe également un tutoriel sur developpez : Programmation par contrat, application en C++

[Flob90]

Oui via des templates ou des données membres. Dit moi ce qui est déterminé à la compilation et ce qui l'est à l'execution, je pourrais (essayer) te faire un exemple pour te donner une idée.

[Lintel-oo]

@gbdivers : c'est un tutoriel intéressant mais ceci dit si je tente de le suivre en fonction de mon projet il faut que je repense tout même si c'est effectivement ce sur quoi je m'aiguille

@flob90 : j'ai énormément de mal à discerner les 2 même si je sais que c'est totalement différent .

Je dirais que pour ce qui s'agit de la compilation, les comportements des différents types de curve sont établis, c'est à dire leur formulation explicite en fonction de x, ainsi que leur dérivée, leur tableau de variation et de signe.

Pour ce qui est de l’exécution, je dirais que ce qui est déterminé, c'est le(s) type(s) de courbes utilisés, et leur intervalle de définition, qui peut être modifié si il ne satisfait pas les conditions de base de la courbe (exemple : intervalle [-5;10] ramené à un intervalle [0;10] dans le cas de la fonction racine).

J'insiste sur le fait que j'ai beaucoup de mal à établir précisément le "design" que je cherche