Ne Delphi appel hérité sur remplacées si la procédure d'appel n'est pas explicite

Question

Ne Delphi appel hérité sur remplacées si la procédure d'appel n'est pas explicite dans le code ie (hérité;), j'ai la structure suivante (à partir de super à la sous classe)

TForm >> TBaseForm >> TAnyOtherForm

Tous les formulaires du projet sera dérivée de TBaseForm, ce qui permettra d'avoir tous les set-up et destructif de pièces qui sont utilisés pour chaque formulaire (la sécurité, la validation ect).

TBaseForm a onCreate et onDestroy procédures avec le code pour faire cela, mais si quelqu'un (c'est à dire moi) oublié d'ajouter hérité de la onCreate sur TAnyOtherForm serait Delphi appel est-il pour moi?J'ai trouvé des références sur le web qui disent qu'il n'est pas nécessaire, mais rien ne dit si elle est appelée, si elle est omise, à partir du code.

Aussi, si elle ne fait appel hérité pour moi, quand il l'appeler?

Answer 1

Non, si vous laissez l'appel à hérité de suite, il ne sera pas appelé.Sinon, il ne serait pas possible de remplacer une méthode et totalement omettre la version parent d'elle.

Answer 2

Il est important de mentionner que, en n'appelant pas hérité de destruction de tout objet peut provoquer des fuites de mémoire.Il existe des outils disponibles pour vérifier cela dans votre code source.

Answer 3

Les hérité d'appel doit être faite de manière explicite.En général, une langue n'appelle automatiquement le héritée de la fonction dans des situations équivalentes (constructeurs de classe non inclus).

Il est facile d'oublier de faire de l'héritage appel à un constructeur de la classe.Dans une telle situation, si une classe de base doit initialiser toutes les données que vous avez une violation d'accès en attente de se produire.

Peut-être que vous pourriez remplacer DoCreate et DoDestory dans votre TBaseForm classe, donc vous pouvez vous assurer du code est exécuté indépendamment de la mise en œuvre de classes enfant.

// interface

TBaseForm = Class(TForm)
...
Protected
    Procedure DoCreate(Sender : TObject); Override;
End

// implementation

Procedure TBaseForm.DoCreate(Sender : TObject);
Begin
    // do work here

    // let parent call the OnCreate property  
    Inherited DoCreate(Sender);
End;

Answer 4

Hérité doit être appelée explicitement dans les objets descendants ainsi que dans la forme visuelle de l'héritage.Si vous utilisez la classe d'achèvement, puis il ajoute hérité automatiquement si vous ajoutiez la définition remplacer (mais pas pour réintroduire).Si vous utilisez visual forme d'héritage lorsque vous ajoutez un nouvel événement virage grâce à l'éditeur de formulaire, puis il va ajouter hérité ainsi.

Answer 5

Hérité du code n'est pas appelé implicitement, comme les autres l'ont indiqué.Vous devez appeler explicitement.Cela vous donnera une flexibilité utile.Par exemple, vous pourriez faire quelques prétraitement code avant de l'héritage de code, puis faire un peu de post-traitement de code par la suite.Cela pourrait ressembler à:

procedure TMyCalcObject.SolveForX;
begin
  ResetCalcState;
  inherited SolveForX;
  PostProcessSolveForX;
end;

Answer 6

Pas de.C'est toute la question de l'annulation de la.

Answer 7

Vous devez appeler explicitement.Cela permet une grande flexibilité, puisque vous pouvez choisir à quel moment de code pour appeler la méthode héritée.Mais c'est aussi une grande source de bugs.Il est facile d'oublier d'appeler les hérité de la fonction et le compilateur n'a aucun moyen de dire si vous n'avez délibérément ou vous avez tout simplement oublié.

Il devrait y avoir une sorte de directive "skip_inherited" dire compilateur que vous ne souhaitez pas appeler la méthode héritée.

Compilateur serait alors facilement le rapport d'erreur si il n'a pas trouver d' "hérité" ou "skip_inherited".Cela voudrait dire que vous avez oublié.Mais malheureusement personne dans CodeGear pensé.