sigo con la idea de Hector.
Las propiedades son útiles también para introducir "efectos secundarios".
Supongamos que estas programando una clase:
Código Delphi
[-]
TEtiquetaV = class(TObject)
public
Mensaje : string;
end;
TEtiquetaP = class(TObject)
FMensaje: string;
public
property Mensaje: string read FMensaje write FMensaje;
Mas adelante... mientras vas programando el sistema, te das cuenta que queres que el mensaje de la etiqueta se actualice automáticamente en la pantalla cuando el programador lo asigne, de manera que el usuario tenga un retorno de información adecuado.
Entonces, en lugar de escribir el valor de la propiedad directamente en FMensaje, creas un método SetMensaje (o cualquier otro nombre, aunque esta es la convención) y lo implementas algo como:
Código Delphi
[-]
TEtiquetaP = class(TObject)
FMensaje: string;
procedure SetMensaje(const Value: string);
public
property Mensaje: string read FMensaje write SetMensaje;
end;
....
procedure TEtiquetaP.SetMensaje(const Value: string);
begin
FMensaje := Value;
Repintar();
end;
Luego, te das cuenta que sería de utilidad al programador poder actuar cuando hay un cambio en el valor de la propiedad mensaje de la etiqueta.
Entonces añadis un evento a la clase y lo lanzas cuando cambia el valor:
Código Delphi
[-]
procedure TEtiquetaP.SetMensaje(const Value: string);
begin
FMensaje := Value;
Repintar();
DoOnChange;
end;
En fin... usar propiedades te ayuda a mantener una interfaz consistente al programador a medida que tus clases evolucionan, validar automáticamente los valores que la clase acepta en las propiedades (por ejemplo, solo números pares o impares, etc), introducir efectos secundarios "controlados", lanzar eventos.
Hasta luego.
