delphi surcharge, de remplacer, de méthode virtuelle

simple hiérarchie de l'objet comme ci-dessous

TLiveThing=class
protected
 FTest:string;
 constructor Create(whereLive:string);overload;virtual;
 constructor Create(haveBone:Boolean);overload;virtual;
end;

THuman=class(TLiveThing)
public
 constructor Create(whereLive:string);overload;override;
 constructor Create(age:integer);overload;
end;

en théorie, si j'instancie THuman, j'ai 2 constructeur, mais en fait j'ai 5 constructeur affiché par le code de la perspicacité, en fait, je veux voir 3 constructeur
- Créer(whereLive:String), surchargée
- Créer(âge:entier)
- Créer(haveBone:integer)

human:=THuman.Create(       <=====in there I have 5 suggestion constructor

pourquoi j'ai ce comportement étrange? comment résoudre le problème, parce que ça tellement souvent embêtant, je ne peux toujours vérifier ma classe que j'ai besoin d'instancier, et si j'instancie comme ci-dessous

human:=THuman.Create(); <===== it doesnt give me error

comment j'ai complètement cacher mon anchestor constructeur? parce que si je démarrent des instances comme ci-dessus, complètement me donner un mauvais objet

Mise à JOUR: et aussi je peux voir Créer par défaut sans paramètre de TObject trop

Vous avez trop de constructeurs virtuels. Vous avez besoin d'avoir un seul de ceux-ci.
Êtes-vous sûr que vous avez besoin des constructeurs virtuels? Avez-vous jamais en fait instancier une de ces classes sans connaître le type au moment de la compilation? Si pas, alors vous n'avez pas besoin des constructeurs virtuels.
Il est difficile de vous conseiller ici, parce que nous ne savons pas quel est le moteur que vous avez tellement de surcharge et des constructeurs virtuels. Sur le visage de votre ensemble de la conception des odeurs. Mon intuition est que la fixation du design permettra de résoudre les problèmes. Tenter de masquer les constructeurs s'apparente à mettre des vêtements peg sur votre nez. La conception encore des relents, vous ne pouvez pas le sentir.
oke, je mets à jour ma question pour préciser mon point de vue, parce qu'en fait dans mon code, à la fois constructeur ont complètement différent paramètre et j'ai parfois besoin de remplacer à la fois du constructeur de la classe de base, et parfois je viens d'utiliser le constructeur de la classe de base. Bien sûr, je peux renommer un autre constructeur pour CreateByWhereLive ou de quelque chose de différent pour contourner ce problème, et je peux le faire fonctionner correctement, mais si j'utilise "Créer", je ne comprends pas pourquoi il ont un comportement comme ça...
j'ai besoin de tous que la surcharge et virtuel constructeur. je prie de différer. Vous ne devriez pas avoir plus d'un constructeur virtuel. Si vous le faites, votre conception est erronée.

OriginalL'auteur navirius | 2013-05-25

  1. 1

    Sans mettre l'accent sur votre mauvais constructeur de mise en œuvre,

    votre problème, c'est que à la fois l'ancêtre et de l'enfant en classe sont définies dans la même unité, à cet effet, la définition standard du Privé/Protégé ne s'applique pas ici.

    Si vous souhaitez empêcher l'ancêtre du constructeur (qui vous sont prépondérants dans la classe fille) à partir d'un code de paramètre lors de l'instanciation d'un objet de cette derrived classe, puis tout simplement en faire un membre de la stricte protégé ou stricte section privée.

    Avec votre exemple :

    TLiveThing=class
strict protected
 constructor Create(whereLive:string); virtual;
end;

THuman=class(TLiveThing)
public
 constructor Create(whereLive:string); overload; override;
 constructor Create(age:integer); overload;
end;

    Cela permettra d'éviter l'ancêtre constructeur Create(whereLive:string) d'apparaître comme un paramètre lors de la création d'une instance de votre classe enfant.

    Comme l'a souligné David, cela n'a rien à voir avec de cacher le défaut de Créer constructeur, c'est uniquement viable pour cacher votre personnalisé constructeurs.

    Ce qui n'aidera pas du tout. Le sans paramètre TObject.Create est rendue visible par l'introduction d'une surcharge Create. Voir le double.
    Oui, mais il a également ajouté qu'il veut cacher l'ancêtre constructeur Créer(whereLive:string) et ce sera au moins l'aider à le cacher.
    donc, c'est moyen, en delphi, si j'ai virtuels 2 constructeur de la classe de base, puis de la classe dérivée de 1 constructeur et 1 remplacé à partir de la base, puis quand j'instancie un objet de la classe dérivée, je peux avoir 4 constructeur, inclure le remplacé ( j'ai que l'expérience de mon code à ma question) c'est un bug ou juste comme ça? (parce que je n'obtiens pas un comportement comme ça sur c#)
    car, en fait, je ne veux pas cacher certaines constructeur avec la plus stricte privé, je veux juste, que le constructeur est remplacé par des dérivés de la classe, donc si j'instancie un objet, je peux le voir remplacé constructeur juste constructeur d'objet dérivé, mon expérience dans delphi, l'aperçu du code me donner suggestion constructeur de la classe de base et constructeur de la classe dérivée, si j'ai déjà remplacer le constructeur
    la stricte mot n'a pas d'influence sur le remplacement de la directive d'une méthode, le résultat sera le même. Je pense que vous avez confondu par le mot caché dans ma réponse. L'ancêtre virtuel constructeur qui vous a décidé à remplacer dans votre classe dérivée sera toujours surchargé, la parole strict signifie simplement que si les deux Parents et Enfants de la classe sont définies dans la même unité, il va omettre la confusion que vous êtes maintenant en faire l'expérience lors de l'instanciation d'un objet. Vous pourriez obtenir le même résultat en écrivant classe Ancêtre dans Unit1 et de l'Enfant de la classe dans Unite2. Je vais mettre à jour la réponse, j'espère que vous l'acceptez.

    OriginalL'auteur Peter