Objeto global a la aplicación

[noob]

Hola, quiero crear un objeto que sea global a la aplicación, no quiero usar un módulo de datos sino que quiero declarar una clase y crear un objeto que sea accesible en todo momento por mi aplicación desde cada clase. Quiero que este objeto se cree nada más iniciarse la aplicación y que luego pueda acceder a él desde cada unidad.

Ya tengo la clase preparada, ahora sólo me falta crear el objeto y que sea accesible globalmente.

¿Es esto posible?

Saludos.

[[Al González]]

Empezado por noob

...¿Es esto posible?

Sí. Un buen ejemplo de lo que buscas lo tiene la propia VCL en la unidad Menus.pas:

Código Delphi [-]
unit Menus;

...

interface

...

var
  PopupList: TPopupList;

...

implementation

...

// esto se ejecuta al arrancar el programa
initialization
  ...
  PopupList := TPopupList.Create;
  ...

// esto se ejecuta cuando finaliza el programa
finalization
  ...
  PopupList.Free;
  ...
  
end.

(encontrado con Find in Files en Delphi 7)

Observa cómo la unidad ActnPopup.pas hace uso del objeto global:

Código Delphi [-]
unit ActnPopup;

interface

{ Borland agrega la unidad Menus en esta cláusula Uses porque esta sección
  "Interface" requiere elementos de Menus.pas }
uses Classes, Controls, Menus, ActnMenus, XPActnCtrls, ActnMan, ActnList;

...

implementation

{ Pero en este Uses estaría agregada la unidad Menus sí únicamente se
  quisiera acceder a la variable PopupList }
uses SysUtils, Windows, Messages, Forms;

...

procedure TCustomActionPopupMenuEx.ExecAction(Action: TContainedAction);
begin
  PostMessage(PopupList.Window, WM_COMMAND, TMenuItem(FSelectedItem.Tag).Command, 0);
end;

...

end.

(encontrado con Find in Files en Delphi 7)

Espero te sirva, no dejes de comentarnos.

Al González

[noob]

Perdona mi ignorancia pero, ¿cómo puedo adaptarlo a mi programa?

Supongamos que tengo un formulario y dos clases: Form1, cClase2, cClase3.

Form1:

Código Delphi [-]
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

uses Unit2;

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var
  Clase2: cClase2;
begin
  Clase2 := cClase2.Create;
  Clase2.anadir(Edit1.Text);
end;

end.

Unit2:

Código Delphi [-]
unit Unit2;

interface

type
  cClase2 = class
              private
              public
                procedure anadir(Mensaje: string);
            end;

implementation

uses Unit3;

procedure cClase2.anadir(Mensaje: string);
begin
  with Clase3 do
    Contenido := Contenido + Mensaje;
end;

end.

Unit3:

Código Delphi [-]
unit Unit3;

interface

type
  cClase3 = class
              private
              public
                Contenido: string;
            end;

var
  Clase3: cClase3;

implementation

end.

Lo que yo quiero es crear el objeto de la clase cClase3 nada más inicializarse la aplicación para que luego cuando pulse al botón el objeto ya esté creado (como he dicho al principio prescindiendo de un módulo de datos).

[[Al González]]

Empezado por noob

Perdona mi ignorancia pero, ¿cómo puedo adaptarlo a mi programa?

Supongamos que tengo un formulario y dos clases: Form1, cClase2, cClase3...

Parece que sólo te faltaría agregar las secciones de inicialización y finalización en la unidad Unit3, que sería como la unidad Menus.pas del ejemplo que te di.

[noob]

Lo tengo y funciona, muchas gracias.

Form1:

Código Delphi [-]
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Unit2;

type
  TForm1 = class(TForm)
    Button1: TButton;
    Edit1: TEdit;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
  private
    { Private declarations }
    Clase2: cClase2;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.FormCreate(Sender: TObject);
begin
  Clase2 := cClase2.Create;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  Clase2.anadir(Edit1.Text);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  Clase2.mostrar;
end;

end.

Unit2:

Código Delphi [-]
unit Unit2;

interface

type
  cClase2 = class
              private
              public
                procedure anadir(Mensaje: string);
                procedure mostrar;
            end;

implementation

uses Unit3, Dialogs;

procedure cClase2.anadir(Mensaje: string);
begin
  with Clase3 do
    Contenido := Contenido + Mensaje;
end;

procedure cClase2.mostrar;
begin
  ShowMessage(Clase3.Contenido);
end;

end.

Unit3:

Código Delphi [-]
unit Unit3;

interface

type
  cClase3 = class
              private
              public
                Contenido: string;
            end;

var
  Clase3: cClase3;

implementation

initialization

  Clase3 := cClase3.Create;

finalization

  Clase3.Free;

end.

[[Al González]]

Empezado por noob

Lo tengo y funciona, muchas gracias.

De nada Noob, gracias a ti por hacer buenas preguntas. Así es como los foros de Club Delphi se han convertido en un deslumbrante acervo de información técnica.

Por cierto, te recomiendo usar Free en lugar de Destroy, por las razones que se explican en varios hilos que hablan de ello.

Un saludo.

Al.

[noob]

A veces pienso que mis preguntas son un tanto rebuscadas.

Empezado por Al González

Por cierto, te recomiendo usar Free en lugar de Destroy, por las razones que se explican en varios hilos que hablan de ello.

Edito y tomo nota.

[[Delphius]]

Formalmente lo que buscas es un Singleton. Y la forma en llevarlo a cabo es redefiniendo el método de clase NewInstance y el método FreeInstance.

Luego, debes tener una variable que se puede o no, mantener "oculta" que sea del tipo de la clase definida. ¿Para qué? Para que la implementación de NewInstance pueda chequear si existe una instancia de dicha clase, si existe se devuelve dicha instancia, en otro caso se crea.
FreeInstance liberará la instancia.

Más o menos la idea es algo como esto:

Código Delphi [-]
type
TSingleton = class //nuestra clase que será global
  public
    class function NewInstance: TObject; override;
    procedure FreeInstance; override;
end;

implementation

var Instancia: TSingleton; //Nota como esta variable se mantiene "oculta"

class function TSingleton.NewInstance: TObject;
begin
  if (NOT Assigned(Instancia))
     then begin
            Instancia := TSingleton (inherited NewInstance);
            // algo más que deba hacer....
          end;
  result := Instancia;
end;

procedure TSingleton.FreeInstance;
begin
  Instancia := nil;
  inherithed FreeInstance;
end;

Ahora si deseas puedes hacer que se cree y se libere dicha instancia en sus secciones Initialization y Finalization.

Luego puedes tener cuantas variables donde necesites, cuando hagas algo como:

Código Delphi [-]
Variable := TSingleton.Create;

Variable apuntará a "Instancia". Luego si haces,

Código Delphi [-]
Variable.Free;

Liberas al objeto global, es decir a "Instancia".

Se puede modificar un poco el código para no liberar de una, y llevar un contador de las veces que se referencie: NewInstance incrementa el contador, mientras que FreeInstance lo decrementa.

Nomás te cuento esto como alternativa. Hay muchas maneras de implementar un singleton.

La forma que comentó Al es una de ellas. Pero funcionará siempre y cuando usemos la variable que se declara en Interface. Si uno tiene otra variable de la misma clase, puede correr el riesgo de crearla y liberarla, por tanto habrá dos instancias y se rompe el esquema de la variable global (y única).
Ojo, que con el esquema que menciona Al, no hay que liberarla nunca sino dejar que el sistema al finalizar solito se encargue de ello.

Saludos,

[noob]

@Delphius he estado usando el esquema de Al pero voy a usar lo que me has recomendado por el tema de no crear más que una instancia.

Cuatro cosas:

1) ¿TSigleton ha de ser mi clase cClase3?

2) He visto que redefines los métodos NewInstance y FreeInstance pero la clase TSingleton no hereda de ninguna otra, ¿qué se redefine entonces?

3) ¿Variable := TSingleton.Create; y Variable.Free; lo he poner en las secciones de inicialización y finalización de mi clase singleton?

4) ¿Quedaría así?

Código Delphi [-]
unit Unit3;

interface

type
  cClase3 = class
              private
                Contenido: String;
                function ObtenerContenido: String;
                procedure EstablecerContenido(Contenido: String);
              public
                class function NewInstance: TObject; override;
                procedure FreeInstance; override;
                property PropContenido: String read ObtenerContenido
                                               write EstablecerContenido;  
            end;

implementation

var Clase3: cClase3; //Nota como esta variable se mantiene "oculta"

function cClase3.ObtenerContenido: String;
begin
  Result := Contenido;
end;

procedure cClase3.EstablecerContenido(Contenido: String);
begin
  Self.Contenido := Contenido;
end;

class function cClase3.NewInstance: TObject;
begin
  if (NOT Assigned(Clase3))
     then begin
            Clase3 := cClase3 (inherited NewInstance);
            // algo más que deba hacer....
          end;
  result := Clase3;
end;

procedure cClase3.FreeInstance;
begin
  Clase3 := nil;
  inherithed FreeInstance;
end;

initialization

  Clase3 := cClase3.Create;

finalization

  Clase3.Free;

end.

Saludos.

[[Delphius]]

Empezado por noob

@Delphius he estado usando el esquema de Al pero voy a usar lo que me has recomendado por el tema de no crear más que una instancia.

Cuatro cosas:

1) ¿TSigleton ha de ser mi clase cClase3?

Será la clase que deba ser... en tu caso es cClase3.
Por otro lado, sería oportuno que siguieras la nomenclatura que sigue Delphi: Anteponer T (que hace alusión a que se trata de un tipo) al nombre.
Si bien no estás cometiendo un delito y es a elección propia el seguir una nomenclatura, es recomendable mantener un código homogéneo.

Empezado por noob

2) He visto que redefines los métodos NewInstance y FreeInstance pero la clase TSingleton no hereda de ninguna otra, ¿qué se redefine entonces?

Toda clase desciende, directa o indirectamente, de la clase base TObject.
NewInstance y FreeInstance son dos métodos virtuales declarados en TObject.
En este caso TSingleton desciende de TObject (si uno no define la clase en class el compilador asume y entiende que se desciende de TObject).

Empezado por noob

3) ¿Variable := TSingleton.Create; y Variable.Free; lo he poner en las secciones de inicialización y finalización de mi clase singleton?

En donde gustes. Pero si leyeras con atención, "Variable" es una variable declarada fuera... es decir que no pertenece a la unidad en donde se declara el singleton. Es la variable que se usa para acceder al singleton.

En mi código claramente se ve que existe una variable "Instancia" que mantiene referencia al singleton. Esta variable no puede ser leída desde afuera. Luego, para hacer uso del singleton es que uno hace uso de "Variable" y de forma indirecta "Variable" apunta hacia "Instancia".

En tu caso, reemplazaste "Instancia" por "clase3".

Ahora yo te pregunto... ¿Y como usas al singleton?
¿Ves para que existe "Variable"?

Variable no debería (o tal vez... habría que ver) inicializarse en initialization, y liberarse en Finalization.
Variable "se crea" en donde se necesita emplear al singleton, y el tiempo de vida de "Variable" se ajustará a las necesidades. Recuerda que si haces Free de "Variable" estás liberando al objeto global Por ello indico que existen diferentes formas de como llevarlo.

Una forma típica es tener un contador de instancias. De ese modo en cada "Create" de "Variable" se incrementa, y en cada "Free" se decrementa. Al llegar a cero, se libera el objeto global. De este modo evitamos que cualquier Free que tengamos por allí libere al singleton.

Empezado por noob

4) ¿Quedaría así?

Si, así podría quedar.
Recuerda que necesitarás tener una "Variable" afuera, si no la publicas.

Una variación de mi TSingleton puede ser hacer público a "Instancia", de este modo nos evitamos tener "Variables". Pero en caso de hacerla pública, debe recordarse de que en ningún momento liberarla ya que el trabajo se hará al finalizar el sistema.

Espero que con esto se entienda la idea.
Por si no se entiende, lee éste artículo.

Es más, como muestra de que hay diferentes enfoques de como llevar un singleton (cada uno tiene sus pros y contras y deben analizarse cual es conveniente en cada caso) se puede concebir un modelo mixto entre el ejemplo de Al y el "mío" (Digo mío entre comillas porque he seguido (y sigo) el artículo):

Declarar el singleton en una unidad, y tener otra unidad, global, con "Variable" de forma global. Pero claro... este enfoque puede resultar un poco... inpráctico puesto que se está elevando el acoplamiento. Ahora bien, si en dicha unidad... por denominarla de un modo... UGlobal se emplea para acoplar otros objetos que también merezcan un carácter global si es recomendable.
De este modo se independiza (y se permite cierta reutilización) un poco las declaraciones de posibles objetos Singleton de las variables singleton.

Bueno, creo que esto ya complementa desde diferentes ángulos el tema, y me hizo reanalizar este penúltimo párrafo (no había visto hasta el momento ésa opción). Creo que añadiré esta observación y punto de vista en mi hoja de observaciones de éste patrón. Te agradezco noob por hacerme descubrir que este patrón da para más de lo que creía.

Saludos,

[noob]

Pienso que mi singleton no funciona porque puedo declarar más de una variable de mi clase singleton:

Unit1:

Código Delphi [-]
unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Unit2;

type
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
    Clase2: TClase2;
    Clase2b: TClase2;
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  Clase2 := TClase2.Create;
  Clase2b := TClase2.Create; // No debería dejarme crear esta instancia porque se supone que es un singleton
end;

end.

Unit2:

Código Delphi [-]
unit Unit2;

interface

type
  TClase2 = class
              private
                Contenido: String;
                function ObtenerContenido: String;
                procedure EstablecerContenido(Contenido: String);
              public
                class function NewInstance: TObject; override;
                procedure FreeInstance; override;
                property PropContenido: String read ObtenerContenido
                                               write EstablecerContenido;
            end;

implementation

var Clase2: TClase2; //Nota como esta variable se mantiene "oculta"

function TClase2.ObtenerContenido: String;
begin
  Result := Contenido;
end;

procedure TClase2.EstablecerContenido(Contenido: String);
begin
  Self.Contenido := Contenido;
end;

class function TClase2.NewInstance: TObject;
begin
  if (NOT Assigned(Clase2))
     then begin
            Clase2 := TClase2 (inherited NewInstance);
            // algo más que deba hacer....
          end;
  result := Clase2;
end;

procedure TClase2.FreeInstance;
begin
  Clase2 := nil;
  inherited FreeInstance;
end;

end.

[[Delphius]]

Hola noob, está bien. La cuestión es que puedes tener tantas variables como necesites. Pero si te fijas, todas "apuntan" a un mismo objeto. Por tanto, se trata de una única instancia que es referenciada desde diversos puntos.

La alternativa de Al evita estar definiendo variables, y trabajar con una única... la que se declara como pública en dicha unidad. Pero si la declaración de la clase es de acceso público (interface), nada impide declarar una nueva variable y crearla. Rompiendo así el principio de una única instancia (a menos claro que dicha clase redefina los métodos tal como los he señalado en mi ejemplo).

Obviamente, el peligro de tener muchas variables es el manejo de ciclo de vida. Si alguna de esas variables se libera, se libera el singleton. Pero lo bueno de ésto es que si uno aprovecha sabiamente el método de clase NewInstance y el método FreeInstance puede hacer que se ante un posible Free, no se libere el único objeto que existe.

Para entender apropiadamente como funciona el patrón añade muchas variables, y algunos breackpoint en el momento del Create... si vas siguiendo con F7 notarás que en el primer Create (si es que no se hace uso de un Create, en initialization) se crea la única instancia. En los sucesivos Create, lo que se hace es apuntar a dicha instancia. Esto es así debido a la simple condición:

Código Delphi [-]
if Assigned(Instancia) then ... result := Instancia

Lee el artículo que te he hecho llegar. Eso te permitirá comprender mejor el patrón.

No es por ser molesto, pero copiar por copiar no sirve. Hay que leer un poquito.

Saludos,

[roman]

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;

{ 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
    { ISingleton }
    function GetAuthor: String;
    procedure SetAuthor(Value: String);
  end;

{ TSingleton }

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

[[Al González]]

¡Hola!

Bueno, continuando con la singletonmanía , ahí les va mi propuesta:

Código Delphi [-]
Unit UUnico;

Interface

  Type
    TUnico = Class
      Class Function NewInstance :TObject; Override;
      Procedure FreeInstance; Override;
    End;

  Function Unico :TUnico;  // Función global para acceder a la instancia

Implementation

  Uses
    SysUtils;

  Var
    Instancia :TUnico;  // Variable privada que apuntará a la instancia
    Bloqueado :Boolean;  // Bandera de control

  Class Function TUnico.NewInstance :TObject;
  Begin
    If Bloqueado Then
      Raise Exception.Create ('Intento de crear nuevamente objeto Unico.');

    Result := Inherited NewInstance;
  End;

  Procedure TUnico.FreeInstance;
  Begin
    If Bloqueado Then
      Raise Exception.Create (
        'Intento de destruir prematuramente objeto Unico.');

    Inherited FreeInstance;
  End;

  Function Unico :TUnico;
  Begin
    // a) Creamos la instancia cuando sea requerida por primera vez o...
    If Instancia = Nil Then
    Begin
      Instancia := TUnico.Create;
      Bloqueado := True;
    End;

    Result := Instancia;
  End;

Initialization
  // ...b) Creamos la instancia desde que inicie el programa
  Instancia := TUnico.Create;
  Bloqueado := True;

  // NOTA: Utilice la opción "a" o la opción "b", pero no ambas.

Finalization
  // Destruimos la instancia hasta que finalice el programa
  Bloqueado := False;
  Instancia.Free;

End.

Código Delphi [-]
Uses
  UUnico;

procedure TForm1.Button1Click(Sender: TObject);
Var
  U :TUnico;
begin
  ShowMessage (Unico.ClassName);

  // Imposible
  U := TUnico.Create;

  // Imposible
  Unico.Free;

  // Imposible
  U := Unico;
  U.Destroy;
end;

El problema que veo en el esquema sugerido por Marcelo es que permite nuevas sentencias de instanciación (TSingleton.Create), que darían lugar a re-ejecutar el código del constructor, a pesar de que no se crea una instancia nueva. Si el objeto ya existe, creo que no tendría por qué ser ejecutado el código de su constructor cada vez que alguna parte del programa vaya a usar ese objeto.

La solución con interfaz de Román es efectiva porque consigue que no pueda ser construido el objeto por segunda vez ni destruido prematuramente. El esquema que propuse ahora no es más que otra manera de lograr eso mismo.

Saludos.

Al González.

[[Delphius]]

¡Hola!

Vuelvo de una rica cena y me encuentro con esto de postre.

Debo decir que ambos postres son deliciosos.
En efecto, sus soluciones son más convenientes. Nomás yo me he limitado a dar lo "básico", en cierto modo, de como se puede enfocar el problema.

Mientras estaba realizando un estudio y análisis (hace ya unos meses) del patrón me dí cuenta de los problemas que implica el esquema que yo había estudiado. Por ello empecé a practicar diferentes enfoques y me dí cuenta de que hay muchas formas, algunas más "ingeniosas" que otras.

Llegué a opciones similares como la que han descrito, y una de las que más me convence a mi es tener una función GetSingleton o GetInstance como la de roman para acceder a un único objeto.

Mis prácticas me llevaron por interfaces, que es una opción bastante elegante y que no requiere de mucho lío y código ya que como bien señala roman, gracias al conteo de referencia es que se consigue liberar todo automáticamente. Y también practiqué llevandolo hacia herencia, es decir algo como:

Código Delphi [-]
Type
  TAbstractSingleton = class
   ...
   end;

  TConcreteSingleton = class(TAbstractaSingleton)
  ...
  end;

Detuve mis avances cuando quise meterme en un esquema thread-safe debido a que no domino el tema de los hilos, el uso de secciones críticas, mútex y cosas por el estilo. Encontré algunos artículos que mencionaban algo al respecto pero no termino de comprender el tema.
Si alguien se anima a enriquecer el hilo con una versión tread-safe les estaría agradecido (y también noob).

Saludos,

[noob]

Empezado por Delphius

Hola noob, está bien. La cuestión es que puedes tener tantas variables como necesites. Pero si te fijas, todas "apuntan" a un mismo objeto. Por tanto, se trata de una única instancia que es referenciada desde diversos puntos.

Pensé que se creaba más de una instancia, no cai en eso.

Muchas gracias a todos por dar estas ricas versiones del patrón Singleton.

Me gusta la opción de acceder al objeto global mediante la función GetInstance y no tener que llamar al método constructor.

Empezado por roman

debe haber un objeto de la clase, y éste se crea usando el constructor privado (que basta declarar, no hay nada necesario que implementar).

Dos dudas roman:

1) Cuando en la sección de inicialización de tu unidad Singl haces: Instance := TSingleton.CreateInstance; ¿se crea realmente una instacia? Lo digo porque el método constructor CreateInstance no está implementado.

2) ¿Los métodos GetAuthor y SetAuthor del interfaz ISingleton no deberían de ser virtuales y abstractos para luego ser redefinidos en TSingleton?

Saludos.

[roman]

Empezado por noob

1) Cuando en la sección de inicialización de tu unidad Singl haces: Instance := TSingleton.CreateInstance; ¿se crea realmente una instacia? Lo digo porque el método constructor CreateInstance no está implementado.

De hecho, TObject.Create está también implementado como un método vacío:

Código Delphi [-]
constructor TObject.Create;
begin
end;

No importa qué constructor uses, el mero hecho de serlo hace que el compilador inserte entre el begin y la primera instrucción (si la hay) una llamada a la función _ClassCreate que es la encargada de construir la base del objeto (mediante el método NewInstance).

En otras palabras, el efecto de Create y de CreateInstance es exactamente el mismo: ambos tienen implementación vacía, pero por estar etiquetados como constructores generan la llamada a _ClassCreate.

El único objetivo de introducir CreateInstance es el de invalidar el constructor público para que no pueda usarse externamente.

Empezado por noob

2) ¿Los métodos GetAuthor y SetAuthor del interfaz ISingleton no deberían de ser virtuales y abstractos para luego ser redefinidos en TSingleton?

En una interfaz el uso de la directivas virtual y abstract sería redundante, porque, de hecho, todos los métodos de una interfaz son virtuales y abstractos por naturaleza. Virtuales porque su implementación dependerá precisamente de la clase que implemente la interfaz y abstractos porque una interfaz no implementa nada por sí sola.

// Saludos

[noob]

En una interfaz el uso de la directivas virtual y abstract sería redundante, porque, de hecho, todos los métodos de una interfaz son virtuales y abstractos por naturaleza. Virtuales porque su implementación dependerá precisamente de la clase que implemente la interfaz y abstractos porque una interfaz no implementa nada por sí sola.

Pensé que era necesario indicarlo.

Roman más dudas:

1) Siempre me gusta separar cada clase en una unidad distinta, en el caso de la unidad Singl2 ¿lo has hecho en una sola unidad a propósito o lo has hecho así por tenerlo todo más visible a la hora de verlo en el foro?

2) ¿No puedo acceder al método Author por medio de una propiedad tal que así?

Código Delphi [-]
property PropAuthor: String read GetAuthor
                            write SetAuthor;

3) Otra cosa, para usar la instancia desde fuera del interfaz, sería así, ¿verdad?

Código Delphi [-]
ShowMessage(Singl2.GetInstance.GetAuthor);

Siento preguntar cosas que tal vez sean muy básicas.

Gracias.

[Kipow]

Interesante el tema, me tomo la libertad de contestarte tus ultimas preguntas noob.

1. Singl2 es la version 2 del ejemplo que roman coloco.
2 y 3. La forma de acceder al singleton seria en todo caso asi

Código Delphi [-]
uses 
   Singl2;

begin
     ShowMessage(GetInstance.Author);   
end

.

ya que GetInstance es una funcion que te retorna la clase. talvez un nombre mas practico podria ser

Código Delphi [-]
function Singleton : TSingleton

Que fue como Al Gonzalez lo recomendo en su propia version.

Saludos.

[Neftali [Germán.Estévez]]

Empezado por kikin

mira la guia de estilo

¿Y a qué viene eso?
Que conste que no estoy en contra de revisarla de vez en cuando¡, pero tanta insistencia... 1 y 2

Perece que se te quedó el teclado "atascado"...