Siempre me ha llamado la atención el uso de este patrón. En cierta forma, creo yo, un
singleton debe ser tan claro su uso que no pueda prestarse a confusión acerca de si se deben o no crear más instancias. Por ejemplo, el objeto Application en cualquier aplicación VCL de Delphi es un
singleton, y aunque sería posible crear otro objeto de la clase TApplication, no conozco a nadie que lo haga, ni siquiera por error.
En todo caso, les doy mi versión del mismo patrón:
Código Delphi
[-]
unit Singl;
interface
uses
SysUtils;
type
TSingleton = class
private
FAuthor: String;
constructor CreateInstance;
public
property Author: String read FAuthor write FAuthor;
constructor Create;
class function GetInstance: TSingleton;
end;
implementation
var
Instance: TSingleton;
constructor TSingleton.Create;
begin
raise Exception.Create('Cannot instantiate this');
end;
constructor TSingleton.CreateInstance;
begin
end;
class function TSingleton.GetInstance: TSingleton;
begin
Result := Instance;
end;
initialization
Instance := TSingleton.CreateInstance;
finalization
Instance.Free;
end.
Aquí, la clase TSingleton declara el constructor Create pero lo invalida lanzando una excepción. Con esto se evitaría que alguien intente crear un objeto de esta clase. El invalidar el constructor serviría para quitar la sensación de que pueden crearse más de una instancia, tal como pensó
noob.
Ahora bien,
debe haber un objeto de la clase, y éste se crea usando el constructor privado (que basta declarar, no hay nada necesario que implementar).
Para acceder a dicho objeto único se usa el método de clase GetInstance.
Claro que aquí queda el problema que menciona
Delphius acerca de que alguien libere el objeto antes de tiempo.
Entonces les presento mi versión 2 del
singleton, esta vez, uando interfaces:
Código Delphi
[-]
unit Singl2;
interface
type
ISingleton = interface
function GetAuthor: String;
procedure SetAuthor(Value: String);
property Author: String read GetAuthor write SetAuthor;
end;
function GetInstance: ISingleton;
implementation
var
Instance: ISingleton;
type
TSingleton = class(TInterfacedObject, ISingleton)
private
FAuthor: String;
public
function GetAuthor: String;
procedure SetAuthor(Value: String);
end;
function TSingleton.GetAuthor: String;
begin
Result := FAuthor;
end;
procedure TSingleton.SetAuthor(Value: String);
begin
FAuthor := Value;
end;
function GetInstance: ISingleton;
begin
Result := Instance;
end;
initialization
Instance := TSingleton.Create;
end.
En este caso, no hay ningún objeto al que pueda accederse directamente, vamos, ni siquiera la clase está visible al público, así que no podemos ni crear instancias ni destruirlas.
El
singleton se accede a partir de la función GetInstance. Dado que la clase que implementa la interfaz desciende de TInterfacedObject, la destrucción del objeto se hará automáticamente cuando se pierda la última referencia. Así, podemos tener cuantas referencias queramos al
singleton, sin preocuparnos por su tiempo de vida.
Bueno, esto no es para invalidar las otras opciones sino sólo para ofrecer un par de alternativas que pueden funcionar en algunas circunstancias.
// Saludos