Llamada Delphi heredada en procedimientos reemplazados si no hay una llamada explícita

Question

Llamada Delphi heredada en procedimientos reemplazados si no hay una llamada explícita en el código, es decir (heredada;), tengo la siguiente estructura (de super a subclase)

TForm >> >> TBaseForm TAnyOtherForm

Todas las formas en que el proyecto se deriva de TBaseForm, ya que esto tendrá la puesta en funcionamiento y destructivas partes todo el estándar que se utilizan para cada forma (seguridad, validación ect).

TBaseForm tiene los procedimientos onCreate y onDestroy con el código para hacer esto, pero si alguien (es decir, yo) se olvidó de agregar heredado a la onCreate en TAnyOtherForm ¿Delphi lo llamaría por mí? He encontrado referencias en la web que dicen que no es necesario, pero en ninguna parte se dice si se llama si se omite en el código.

Además, si llama heredado para mí, ¿cuándo lo llamará?

Answer 1

No, si deja la llamada para heredar de distancia, no se llamará. De lo contrario, no sería posible anular un método y omitir por completo la versión principal de este.

Answer 2

La llamada heredada debe hacerse explícitamente. En general, ningún idioma llama automáticamente a la función heredada en situaciones equivalentes (constructores de clase no incluidos).

Es fácil olvidarse de realizar la llamada heredada en un constructor de clase. En tal situación, si una clase base necesita inicializar cualquier información, tiene una violación de acceso esperando a suceder.

Quizás podría anular DoCreate y DoDestory en su clase TBaseForm para que pueda asegurarse de que se ejecute algún código independientemente de la implementación de clases secundarias.

// 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 3

Vale la pena mencionar que no llamar heredado en Destrucción de cualquier objeto puede causar pérdidas de memoria. Hay herramientas disponibles para verificar esto en su código fuente.

Answer 4

El código heredado no se llama implícitamente, como los otros han indicado. Debe llamarlo de manera explícita. Esto te da una flexibilidad útil. Por ejemplo, es posible que desee hacer algún código de preproceso antes del código heredado, luego haga un código de procesamiento posterior. Esto podría parecerse a:

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

Answer 5

No. Ese es el punto de anulación.

Answer 6

Heredado debe llamarse explícitamente en objetos descendientes así como también en herencia de formas visuales. Si usa la finalización de clase, agrega heredada automáticamente si marcó la definición como anulación (pero no para reintroducirla). Si está utilizando la herencia de formas visuales, cuando agrega un nuevo evento a través del editor de formularios, también se agregará heredado.

Answer 7

Debe llamarlo explícitamente. Esto permite mucha flexibilidad, ya que puede elegir en qué punto del código llamar al método heredado. Pero también es una gran fuente de errores. Es fácil olvidarse de llamar a la función heredada y el compilador no tiene forma de saber si lo hizo deliberadamente o simplemente lo olvidó.

Debe haber algún tipo de directiva "skip_inherited" para indicar al compilador que no desea llamar al método heredado.

El compilador informará fácilmente el error si no encuentra ni "heredado" ni "skip_inherited". Eso significaría que te olvidaste. Pero desafortunadamente nadie en CodeGear pensó en eso.