8 replies to this topic

[Delphius]

Constructores y Destructores

En esta nueva oportunidad hablaremos de los constructores y destructores. No, no es que existe una pandilla que construye código y otra que lo destruye.
Bueno, fueras broma, nos estamos refiriendo a los constructores y destructores que posee una clase.

Cuando uno desea crear un objeto, hace normalmente esto:

delphi

Objeto := TObjecto.Create;

Y con ello ya tiene en memoria una instancia de dicha clase.
Create es el constructor y se encarga de inicializar algunos o todos los atributos del objeto una vez que se ha reservado la memoria. Luego cuando ya no es necesario el objeto, simplemente se lo libera de memoria:

delphi

Objeto.Free;

El método Free envía el mensaje Destroy y éste último se encarga de liberar la memoria. Destroy es el destructor.

Un constructor y destructor no es más que otro método, con la salvedad en que en vez de definirlo como procedimiento o función se emplean las palabras "constructor" y "destructor" respectivamente. Por ejemplo:

delphi

type
  TPerro = class(TMamifero)
  ...
  public
  ...
  constructor Create;
  destructor Destroy; override;
  end;

Luego en su implementación se ve algo como esto:

delphi

constructor TPerro.Create;
begin
  inherited Create;
  // algunas inicializaciones
end;
 
destructor TPerro.Destroy;
begin
  // algunas operaciones de interés y liberaciones de objetos dependientes
  inherited Destroy;
end;

Como puede apreciarse, a Destroy le he añadido la clásula override. Es fundamental declararla puesto que el constructor Destroy es virtual en TObject. En este ejemplo es redundante tanto el constructor como el destructor ya que el mismo constructor y Destructor de la clase TObject se encarga de la administración de memoria de los métodos simples.
Y además, se ve que intenamente se invoca al constructor y destructor de la clase TObject, al establecer la clásula inherited. Esto es necesario para que el constructor y destructor que definimos funcione apropiadamente. De éste modo nos garantizamos de que se inicializan los valores que se necesiten o se heredan desde TObject.

¿Cuando debemos declarar constructores y destructores?

Es necesario cuando entre los atributos, o internamente como alguna variable más, contamos con tipos complejos que requieren de manejo de memoria en forma explícita. Es decir cuando es nuestra responsabilidad manejar el uso de memoria. Por mencionar dos ejemplos: cuando un atributo es una clase o un array dinámico.

Por poner algo más visual. Digamos que queremos que nuestro TPerro tenga la habilidad de criar y mantener a sus crías (obviemos el tema semántico por el momento). Para tener referencia de sus crías podemos hacer uso de TObjectList. De este modo se concibe esta idea:

delphi

type
  TPerro = class
  private
     ListaCrias: TObjectList;
     ...
  public
     ...
     constructor Create;
     destructor Destroy override;
  end;

Como tenemos una clase definida, e internamente vamos a hacer uso de ella. Create es un método candidato (no necesariamente debe ser aquí donde se crea. Depende de diseño y propósitos) para crearla:

delphi

constructor TPerro.Create;
begin
  inherited Create;
  ...
  FListaCrias := TObjectList.Create;
  ...
end;
 
destructor TPerro.Destroy;
begin
  ...
  FListaCrrias.Clear;
  FListaCrias.Free;
  ...
  inherited Destroy;
end;

Como puede apreciarse reservamos la memoria en Create y la liberamos en Destroy.
Continuaremos hablando del tema en otro post.

[Rolphy Reyes]

Saludos.

Estos temas de OOP me fascinan, desde que los vi he estado tratando de comprenderlos, porque en realidad disminuye el código.

Tocando el tema, espero que en las próximas presentaciones comentes sobre Class Function y Class Procedure, que en un sentido pueden pasarse como Constructores.

Otra cosa pienso que te falto mencionar la directiva reintroduce en el constructor, agregada por Borland a partir de la versión 5 para callar al compilador.

[Delphius]

Saludos.

Estos temas de OOP me fascinan, desde que los vi he estado tratando de comprenderlos, porque en realidad disminuye el código.

Tocando el tema, espero que en las próximas presentaciones comentes sobre Class Function y Class Procedure, que en un sentido pueden pasarse como Constructores.

Otra cosa pienso que te falto mencionar la directiva reintroduce en el constructor, agregada por Borland a partir de la versión 5 para callar al compilador.

Hola RolphyReyes,
Tengo pensado hacerlo, aunque no te sabría decir cuando. En la medida en que puedo sacar tiempo, y ordenar ideas, voy llevando estos tutoriales.
Por otro lado, por el tema de reintroduce, no estoy totalmente familiarizado con el concepto. Por lo poco que comprendo, se debe emplear reintroduce cuando se desea sobrecargar un método virtual de una clase base.
Sería bueno que aportaras más sobre este concepto, a modo de ilustrar a los interesados (yo incluído).

Este tutorial no termina con el anterior post. Tengo pensado continuar un poquito más al tema.

Saludos,

[Delphius]

Varios Constructores

Habrá notado que cuando uno desea crear un componente en tiempo de ejecución. el constructor le indica que espera un parámetro. ¿Porqué TPerro y otros ejemplos tratado hasta ahora no tenían que declararlo?

Porque simplemente, nuestros ejemplos están basados en la clase TObject y en ésta el constructor Create no espera parámetro alguno. En cambio la clase TComponent ofrece otro constructor monoparamétrico en el cual se debe indicar el objeto dueño del componente que estamos creando.
Por ello es que cuando uno desea crear cualquier objeto que descienda de la clase TComponent debe indicar este parámetro.

La realidad es que podemos definir más de un constructor. Cada uno con una implementación diferente, que puede recibir o no parámetros. Por ejemplo, supongamos que deseamos crear un perro, e iniciarle un nombre de entrada.

Podemos concebir a TPerro del siguiente modo:

delphi

TPerro = class
  private
    FNombre: string;
  public
    constructor Create;
    constructor CrearConNombre(Nombre: string);
    destructor Destroy; override;
    property Nombre: string read FNombre;
  end;

Y el nuevo constructor podría ser como el que sigue:

delphi

constructor TPerro.CrearConNombre(Nombre: string);
begin
  inherited Create;
  FNombre := Nombre;
end;

Ahora pruebe el siguiente código:

delphi

procedure TForm1.Button1Click(Sender: TObject);
var Perro: TPerro;
begin
  Perro := TPerro.CrearConNombre('Marcelo');
  ShowMessage(Perro.Nombre);
  FreeAndNil(Perro);
 
  Perro := TPerro.Create;
  ShowMessage(Perro.Nombre);
  FreeAndNil(Perro);
end;

Deberá recibir dos cuadros de diálogo. El primero con el texto "Marcelo" y el segundo con el nombe "Fido".
De igual modo es permisible sobrecargar el constructor de éste modo:

delphi

constructor Create; overload;
constructor Create(Nombre: string); overload;

Las mismas reglas que se aplican a cualquier otro método son válidas para el constructor.

¿Porqué Free y no directamente Destroy?

Uno puede pensar que si Destroy es quien libera la memoria ¿porqué no usarlo de forma directa?
El motivo, Free es un medio seguro, ya que realiza un chequeo de último momento: analiza si el objeto en realidad existe.

delphi

procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

Es decir, que antes de liberar la memoria se comprueba de que exista algo por liberar. Supongase de que no existiera el método Free, y debemos hacer uso de Destroy. Ahora altere el último ejemplo con este:

delphi

Perro := TPerro.Create('Marcelo');
ShowMessage(Perro.Nombre);
FreeAndNil(Perro);
 
Perro := TPerro.Create;
ShowMessage(Perro.Nombre);
FreeAndNil(Perro);
 
Perro.Destroy;

Al finalizar toda la rutina debería recibir una excepción EAccessViolation. ¿Porqué? Porque se está intentando eliminar algo que ya fue eliminado. Con Free no se recibe dicha violación, Free es garantía de que si el objeto existiese se lo libere, en otro caso no realiza nada.
En tiempo de diseño no vemos que se está liberando dos veces... siempre puede haber un margen al error y por ello se aconseja muchísimo Free por sobre Destroy. Este ejemplo es sencillo, y tal vez pueda omitirse el Free y valernos de Destroy en forma directa. Pero imagine un código sumamente complejo, en donde intervienen muchas clases, y muchas relaciones. La mejor forma de garantizar de que el objeto sea liberado es emplear Free. De igual forma también debe ser considerado en cuenta que una vez liberado no se haga el intento de seguir empleandolo.

Si usted puede garantizar que siempre se liberará, y que luego no habrá referencia alguna sobre el objeto. Puede hacer uso directo de Free. Más no es algo muy deseable confiarse.

Como observación, puede notar que se llama al método Destroy. Si nuestra clase implementa uno (y por tanto que redefine al de TObject) se hará uso de dicho constructor, en otro caso de invoca al de TObject. Por esto es que se aconseja mucho redefinir el destructor que ya ofrece TObject, en vez de estar declarando uno propio. Como por ejemplo:

delphi

TPerro = class
public
...
destructor Destruir;
end;

Saludos,

[memofer]

Gracias por tus excelente explicaciones, me ayudan a entender mas todo este conecpto de destruir y construir.
Solo quisiera saber si tienes algun tip para saber si un objeto ya fue destruido o no?

[cadetill]

Buenas,

Para saber de la existencia (o no) de un objeto tienes la función Assign

delphi

if Assign(MiObjecto) then // el objeto existe
else // el objeto no existe

Por supuesto también puedes hacer la negación si sólo quieres saber si no existe

delphi

if not Assign(MiObjecto) then // el objeto no existe

Nos leemos

[memofer]

Cadetill

En mi caso, estoy usando RAD Studio XE2 y la funcion Assign(MiObjeto) no me lo identifica como valor booleano
osea que con el

delphi

if Assign(MiObjeto) then
...

no me lo reconoce y verificando la sintaxis de Assign() me dice esto:

Delphi
procedure Assign(Source: TPersistent); virtual;
Description
Copies the contents of another similar object.
Call Assign to copy the properties or other attributes of one object from another. The standard form of a call to Assign is:
Destination.Assign(Source); {Delphi}

No se si tuvieras algun otro tip o consejo.
Gracias.

[cadetill]

Perdón, eso me pasa por hacer las cosas de memoria jejejeje No es Assign, sino Assigned, por lo que sería

delphi

if Assigned(MiObjecto) then // el objeto existe

Nos leemos

[Delphius]

Hola,
Lamento no haber estado antes para responderte. Estoy con pocos tiempos.
Como te han indicado, lo aconsejable es emplear Assigned. Cuya implementación no es más que un if evaluando si el objeto es nil. Es decir, algo como:

delphi

result := Objeto <> nil;

Entonces el resultado será true para cuando el objeto sea distinto a nulo, y falso en caso contrario.

Saludos,