software - delphi technologies

Uso heredado en el constructor "Crear" de un TObject

Question

¿Debo llamar "heredado" en el constructor de una clase derivada de TObject o TPersistent?

constructor TMyObject.Create;
begin
 inherited Create;   // Delphi doc: Do not create instances of TPersistent. Use TPersistent as a base class when declaring objects that are not components, but that need to be saved to a stream or have their properties assigned to other objects.    
 VectorNames := TStringList.Create;
 Clear;
end;

Answer 1

Lo llamo, excepto cuando necesito un constructor muy optimizado.

Answer 2

Sí. No hace nada, es cierto, pero es inofensivo. Creo que vale la pena ser consecuente con llamar siempre al constructor heredado, sin verificar si hay, de hecho, una implementación. Algunos dirán que vale la pena llamar a Create heredado porque Embarcadero podría agregar una implementación para TObject.Create en el futuro, pero dudo que esto sea cierto; rompería el código existente que no llama a Create heredado. Aún así, creo que es una buena idea llamarlo solo por la coherencia.

Answer 3

También puede anular "procedimiento AfterConstruction". Este procedimiento siempre se llama, sin importar qué tipo de constructor.

public
  procedure AfterConstruction; override;
end;

procedure TfrmListBase.AfterConstruction;
begin
  inherited;
  //your stuff, always initialized, no matter what kind of constructor!
end;

Por ejemplo: si desea crear un objeto con un constructor diferente del TObject.Create normal, como TComponent.Create (AOwner) o un constructor personalizado (sobrecargado), puede tener problemas porque su anulación no se llama y (en este caso) su variable "VectorNames" será nula.

Answer 4

Yo siempre hago esto

Si está refactorizando y mueve el código a un antecesor común, invocar el Create heredado tiene las siguientes ventajas:

1. Si el ancestro común tiene un constructor, no puede olvidar llamarlo.
2. Si el ancestro común tiene un constructor con diferentes parámetros, el compilador te advierte de esto.