bonjour,
y'a-t-il une syntaxe particulière qui permette d'exécuter un bout de code
avant que celui du constructuer surchargé soit exécuté?
voici mon cas:
class Base
{
int Reference;
public Base(int Ref)
{
Reference = Ref;
DoSomething();
}
public virtual void DoSomething()
{
// utilisation de la valeur de Reference
}
}
class Derive : Base
{
int Reference2;
public Derive(int Ref1, int Ref2) : base(Ref1)
{
Reference2 = Ref2;
}
public override void DoSomething()
{
base.DoSomething();
// utilisation de la valeur de Reference2
}
}
mon problème est qu'avec ça, quand j'arrive à l'exécution de
Derive.DoSomething, la variable Reference2 ne contient pas Ref2 puisque le
constructuer de Base a été appelé avant celui de Derive.
sachant que cette classe Derive est un cas très particulier d'utilisation
de la classe Base et que ça n'aurait aucune signification d'avoir un
constructeur à 2 paramètres dans Base.
Comment puis-je remédier à ça?
--
*/Teträm/*
http://www.tetram.info
"Humain du matin, petite faim. Humain du soir, pour bien recevoir" -
Proverbe Troll
bonjour,
y'a-t-il une syntaxe particulière qui permette d'exécuter un bout de code
avant que celui du constructuer surchargé soit exécuté?
voici mon cas:
class Base
{
int Reference;
public Base(int Ref)
{
Reference = Ref;
DoSomething();
}
public virtual void DoSomething()
{
// utilisation de la valeur de Reference
}
}
class Derive : Base
{
int Reference2;
public Derive(int Ref1, int Ref2) : base(Ref1)
{
Reference2 = Ref2;
}
public override void DoSomething()
{
base.DoSomething();
// utilisation de la valeur de Reference2
}
}
mon problème est qu'avec ça, quand j'arrive à l'exécution de
Derive.DoSomething, la variable Reference2 ne contient pas Ref2 puisque le
constructuer de Base a été appelé avant celui de Derive.
sachant que cette classe Derive est un cas très particulier d'utilisation
de la classe Base et que ça n'aurait aucune signification d'avoir un
constructeur à 2 paramètres dans Base.
Comment puis-je remédier à ça?
--
*/Teträm/*
http://www.tetram.info
"Humain du matin, petite faim. Humain du soir, pour bien recevoir" -
Proverbe Troll
bonjour,
y'a-t-il une syntaxe particulière qui permette d'exécuter un bout de code
avant que celui du constructuer surchargé soit exécuté?
voici mon cas:
class Base
{
int Reference;
public Base(int Ref)
{
Reference = Ref;
DoSomething();
}
public virtual void DoSomething()
{
// utilisation de la valeur de Reference
}
}
class Derive : Base
{
int Reference2;
public Derive(int Ref1, int Ref2) : base(Ref1)
{
Reference2 = Ref2;
}
public override void DoSomething()
{
base.DoSomething();
// utilisation de la valeur de Reference2
}
}
mon problème est qu'avec ça, quand j'arrive à l'exécution de
Derive.DoSomething, la variable Reference2 ne contient pas Ref2 puisque le
constructuer de Base a été appelé avant celui de Derive.
sachant que cette classe Derive est un cas très particulier d'utilisation
de la classe Base et que ça n'aurait aucune signification d'avoir un
constructeur à 2 paramètres dans Base.
Comment puis-je remédier à ça?
--
*/Teträm/*
http://www.tetram.info
"Humain du matin, petite faim. Humain du soir, pour bien recevoir" -
Proverbe Troll
Erreur classique de design orienté object; qui consiste à vouloir exécuter
plus de code que nécessaire dans les constructeurs. Un constructeur d'object
ne devrait servir qu'à ça; c'est-à-dire construire un object et le rendre
semblable à un formulaire vierge. Une fois la construction terminée, vous
pouvez commencer à l'utiliser en écrivant dedans et en appelant les
propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne devrait
pas être appelée dans le constructeur.
Pour terminer, ce qui est vrai pour les constructeurs l'est également pour
les fonctions régulières: plus vous aller mélanger de fonctionalités dans une
même fonction en lui ajoutant des paramètres, plus votre code va devenir un
labyrinthe.
Erreur classique de design orienté object; qui consiste à vouloir exécuter
plus de code que nécessaire dans les constructeurs. Un constructeur d'object
ne devrait servir qu'à ça; c'est-à-dire construire un object et le rendre
semblable à un formulaire vierge. Une fois la construction terminée, vous
pouvez commencer à l'utiliser en écrivant dedans et en appelant les
propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne devrait
pas être appelée dans le constructeur.
Pour terminer, ce qui est vrai pour les constructeurs l'est également pour
les fonctions régulières: plus vous aller mélanger de fonctionalités dans une
même fonction en lui ajoutant des paramètres, plus votre code va devenir un
labyrinthe.
Erreur classique de design orienté object; qui consiste à vouloir exécuter
plus de code que nécessaire dans les constructeurs. Un constructeur d'object
ne devrait servir qu'à ça; c'est-à-dire construire un object et le rendre
semblable à un formulaire vierge. Une fois la construction terminée, vous
pouvez commencer à l'utiliser en écrivant dedans et en appelant les
propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne devrait
pas être appelée dans le constructeur.
Pour terminer, ce qui est vrai pour les constructeurs l'est également pour
les fonctions régulières: plus vous aller mélanger de fonctionalités dans une
même fonction en lui ajoutant des paramètres, plus votre code va devenir un
labyrinthe.
/_Sylvain Lafontaine_ a exprimé avec précision/ :Erreur classique de design orienté object; qui consiste à vouloir
exécuter plus de code que nécessaire dans les constructeurs. Un
constructeur d'object ne devrait servir qu'à ça; c'est-à-dire construire
un object et le rendre semblable à un formulaire vierge. Une fois la
construction terminée, vous pouvez commencer à l'utiliser en écrivant
dedans et en appelant les propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne
devrait pas être appelée dans le constructeur.
justement, l'appel à DoSomething fait partie intégrante, à mon sens, de
l'initialisation du composant. Si elle a été externalisée dans une
procédure, c'est qu'on peut être amené à l'appeler à nouveau après en
dehors du contexte de création.
Concrêtement, cette fonction va chercher un certain nombre d'informations
en base de données pour renseigner les propriétés de l'objet.
si je ne devrais pas faire comme ça, pour reprendre ma question de départ
toujours sans réponse, comment est-ce que je devrais m'y prendre sachant
qu'une instance de cette classe sans avoir récupéré les données dans la
base n'a *absolument* aucun sens. Comprendre, que l'utilisation de la
fonction d'initialisation des propriétés va être *systématique*. Si j'ai
mis l'appel dans le constructeur, c'est que je ne veux pas avoir à écrire,
à chaque fois:
Derive obj = new Derive();
obj.DoSometing(int1, int2);
si j'ai fait comme ça, aussi, c'est que les méthodes de classes statiques
abstraites ou virtuelles sont impossibles. En fait, à cause de ça, mon
code exact est celui ci:
class Base
{
public Base()
{
// initialisation de l'instance
}
public Base(int int1) : this()
{
// chargement des données initiales
}
}Pour terminer, ce qui est vrai pour les constructeurs l'est également
pour les fonctions régulières: plus vous aller mélanger de fonctionalités
dans une même fonction en lui ajoutant des paramètres, plus votre code va
devenir un labyrinthe.
justement, ici, l'ajout du deuxième paramètre est une utilisation très
particulière et très ciblée de la classe de base. Si je suis passé par un
rajout de paramètre, c'est pour m'éviter d'avoir une deuxième architecture
de classe exactement identique mais qui aurait un paramètre supplémentaire
et qui, finalement, ne serait pratiquement jamais utilisé... tout ça juste
pour être plus joli "orienté objet" parlant
--
*/Teträm/*
http://www.tetram.info
"Tape d'abord, tape ensuite, et tape pour finir" - Proverbe Troll
/_Sylvain Lafontaine_ a exprimé avec précision/ :
Erreur classique de design orienté object; qui consiste à vouloir
exécuter plus de code que nécessaire dans les constructeurs. Un
constructeur d'object ne devrait servir qu'à ça; c'est-à-dire construire
un object et le rendre semblable à un formulaire vierge. Une fois la
construction terminée, vous pouvez commencer à l'utiliser en écrivant
dedans et en appelant les propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne
devrait pas être appelée dans le constructeur.
justement, l'appel à DoSomething fait partie intégrante, à mon sens, de
l'initialisation du composant. Si elle a été externalisée dans une
procédure, c'est qu'on peut être amené à l'appeler à nouveau après en
dehors du contexte de création.
Concrêtement, cette fonction va chercher un certain nombre d'informations
en base de données pour renseigner les propriétés de l'objet.
si je ne devrais pas faire comme ça, pour reprendre ma question de départ
toujours sans réponse, comment est-ce que je devrais m'y prendre sachant
qu'une instance de cette classe sans avoir récupéré les données dans la
base n'a *absolument* aucun sens. Comprendre, que l'utilisation de la
fonction d'initialisation des propriétés va être *systématique*. Si j'ai
mis l'appel dans le constructeur, c'est que je ne veux pas avoir à écrire,
à chaque fois:
Derive obj = new Derive();
obj.DoSometing(int1, int2);
si j'ai fait comme ça, aussi, c'est que les méthodes de classes statiques
abstraites ou virtuelles sont impossibles. En fait, à cause de ça, mon
code exact est celui ci:
class Base
{
public Base()
{
// initialisation de l'instance
}
public Base(int int1) : this()
{
// chargement des données initiales
}
}
Pour terminer, ce qui est vrai pour les constructeurs l'est également
pour les fonctions régulières: plus vous aller mélanger de fonctionalités
dans une même fonction en lui ajoutant des paramètres, plus votre code va
devenir un labyrinthe.
justement, ici, l'ajout du deuxième paramètre est une utilisation très
particulière et très ciblée de la classe de base. Si je suis passé par un
rajout de paramètre, c'est pour m'éviter d'avoir une deuxième architecture
de classe exactement identique mais qui aurait un paramètre supplémentaire
et qui, finalement, ne serait pratiquement jamais utilisé... tout ça juste
pour être plus joli "orienté objet" parlant
--
*/Teträm/*
http://www.tetram.info
"Tape d'abord, tape ensuite, et tape pour finir" - Proverbe Troll
/_Sylvain Lafontaine_ a exprimé avec précision/ :Erreur classique de design orienté object; qui consiste à vouloir
exécuter plus de code que nécessaire dans les constructeurs. Un
constructeur d'object ne devrait servir qu'à ça; c'est-à-dire construire
un object et le rendre semblable à un formulaire vierge. Une fois la
construction terminée, vous pouvez commencer à l'utiliser en écrivant
dedans et en appelant les propriétés et fonctions requises.
À l'évidence, dans votre cas, la fonction virtuelle DoSomething() ne
devrait pas être appelée dans le constructeur.
justement, l'appel à DoSomething fait partie intégrante, à mon sens, de
l'initialisation du composant. Si elle a été externalisée dans une
procédure, c'est qu'on peut être amené à l'appeler à nouveau après en
dehors du contexte de création.
Concrêtement, cette fonction va chercher un certain nombre d'informations
en base de données pour renseigner les propriétés de l'objet.
si je ne devrais pas faire comme ça, pour reprendre ma question de départ
toujours sans réponse, comment est-ce que je devrais m'y prendre sachant
qu'une instance de cette classe sans avoir récupéré les données dans la
base n'a *absolument* aucun sens. Comprendre, que l'utilisation de la
fonction d'initialisation des propriétés va être *systématique*. Si j'ai
mis l'appel dans le constructeur, c'est que je ne veux pas avoir à écrire,
à chaque fois:
Derive obj = new Derive();
obj.DoSometing(int1, int2);
si j'ai fait comme ça, aussi, c'est que les méthodes de classes statiques
abstraites ou virtuelles sont impossibles. En fait, à cause de ça, mon
code exact est celui ci:
class Base
{
public Base()
{
// initialisation de l'instance
}
public Base(int int1) : this()
{
// chargement des données initiales
}
}Pour terminer, ce qui est vrai pour les constructeurs l'est également
pour les fonctions régulières: plus vous aller mélanger de fonctionalités
dans une même fonction en lui ajoutant des paramètres, plus votre code va
devenir un labyrinthe.
justement, ici, l'ajout du deuxième paramètre est une utilisation très
particulière et très ciblée de la classe de base. Si je suis passé par un
rajout de paramètre, c'est pour m'éviter d'avoir une deuxième architecture
de classe exactement identique mais qui aurait un paramètre supplémentaire
et qui, finalement, ne serait pratiquement jamais utilisé... tout ça juste
pour être plus joli "orienté objet" parlant
--
*/Teträm/*
http://www.tetram.info
"Tape d'abord, tape ensuite, et tape pour finir" - Proverbe Troll
> Si vous ne voulez pas l'avoir à écrire à chaque fois, vous n'avez qu'à isoler
la procédure dans une fonction:
Derive CreeObject ()
{
Derive obj = new Derive();
obj.DoSometing(int1, int2);
return obj;
}
Cette logique est différente de celle à tout mettre dans l'appel au
constructeur puisque vous ne créer pas d'ornières pour une utilisation
indépendante de vos objets dans d'autres classes (dérivées ou non).
> Si vous ne voulez pas l'avoir à écrire à chaque fois, vous n'avez qu'à isoler
la procédure dans une fonction:
Derive CreeObject ()
{
Derive obj = new Derive();
obj.DoSometing(int1, int2);
return obj;
}
Cette logique est différente de celle à tout mettre dans l'appel au
constructeur puisque vous ne créer pas d'ornières pour une utilisation
indépendante de vos objets dans d'autres classes (dérivées ou non).
> Si vous ne voulez pas l'avoir à écrire à chaque fois, vous n'avez qu'à isoler
la procédure dans une fonction:
Derive CreeObject ()
{
Derive obj = new Derive();
obj.DoSometing(int1, int2);
return obj;
}
Cette logique est différente de celle à tout mettre dans l'appel au
constructeur puisque vous ne créer pas d'ornières pour une utilisation
indépendante de vos objets dans d'autres classes (dérivées ou non).
Bonjour,
Une seconde opinion si cela peut vous aider dans votre choix....
Comme le précise S. Lafontaine, le constructeur est là pour construire,
pas pour 'meubler'. Vous semblez clairement vouloir 'meubler' de
manière 'implicite'.
Sans vouloir trop m'aventurer dans le "c'est bon", "c'est mauvais", je crois
qu'il n'est jamais bon de vouloir 'impliciter' des choses dans le code.
Encapsuler oui mais pas impliciter.
Vous y verrez un gain car vous êtes le premier utilisateur de cette
fonctionnalité. Votre argument de vouloir créer cette méthode DoSomething
est juste: si l'instance doit subir une nouvelle initialisation après avoir
été instanciée, le développeur doit pouvoir le faire.
Mais la réflexion va également dans l'autre sens, qu'est-ce qui vous garantit
qu'il sera toujours nécessaire d'effectuer cette opération de manière
combinée
lors de l'instanciation ?
De plus, initialiser de manière explicite (appel de la méthode DoSomething
après la construction) l'instance en question pourra vous être bénéfique plus
tard dans le cas d'une éventuelle maintenance ou déboguage.
Finalement , pourquoi ne pas utiliser un constructeur statique ? Ils sont
couramment utilisés lors d'applications de certains 'patterns' de
développement
Juste un avis hein, pas taper = )
Bonjour,
Une seconde opinion si cela peut vous aider dans votre choix....
Comme le précise S. Lafontaine, le constructeur est là pour construire,
pas pour 'meubler'. Vous semblez clairement vouloir 'meubler' de
manière 'implicite'.
Sans vouloir trop m'aventurer dans le "c'est bon", "c'est mauvais", je crois
qu'il n'est jamais bon de vouloir 'impliciter' des choses dans le code.
Encapsuler oui mais pas impliciter.
Vous y verrez un gain car vous êtes le premier utilisateur de cette
fonctionnalité. Votre argument de vouloir créer cette méthode DoSomething
est juste: si l'instance doit subir une nouvelle initialisation après avoir
été instanciée, le développeur doit pouvoir le faire.
Mais la réflexion va également dans l'autre sens, qu'est-ce qui vous garantit
qu'il sera toujours nécessaire d'effectuer cette opération de manière
combinée
lors de l'instanciation ?
De plus, initialiser de manière explicite (appel de la méthode DoSomething
après la construction) l'instance en question pourra vous être bénéfique plus
tard dans le cas d'une éventuelle maintenance ou déboguage.
Finalement , pourquoi ne pas utiliser un constructeur statique ? Ils sont
couramment utilisés lors d'applications de certains 'patterns' de
développement
Juste un avis hein, pas taper = )
Bonjour,
Une seconde opinion si cela peut vous aider dans votre choix....
Comme le précise S. Lafontaine, le constructeur est là pour construire,
pas pour 'meubler'. Vous semblez clairement vouloir 'meubler' de
manière 'implicite'.
Sans vouloir trop m'aventurer dans le "c'est bon", "c'est mauvais", je crois
qu'il n'est jamais bon de vouloir 'impliciter' des choses dans le code.
Encapsuler oui mais pas impliciter.
Vous y verrez un gain car vous êtes le premier utilisateur de cette
fonctionnalité. Votre argument de vouloir créer cette méthode DoSomething
est juste: si l'instance doit subir une nouvelle initialisation après avoir
été instanciée, le développeur doit pouvoir le faire.
Mais la réflexion va également dans l'autre sens, qu'est-ce qui vous garantit
qu'il sera toujours nécessaire d'effectuer cette opération de manière
combinée
lors de l'instanciation ?
De plus, initialiser de manière explicite (appel de la méthode DoSomething
après la construction) l'instance en question pourra vous être bénéfique plus
tard dans le cas d'une éventuelle maintenance ou déboguage.
Finalement , pourquoi ne pas utiliser un constructeur statique ? Ils sont
couramment utilisés lors d'applications de certains 'patterns' de
développement
Juste un avis hein, pas taper = )