Discussion :

[samaury]

Bonjour
Je cherche à implémenter le pattern "Singleton" dans mon appli.
J'ai besoin de changer la visibilité de mon constructeur de classe pour le mettre en "private" ou "protected" et déleguer la construction de mon singleton à une methode de classe du genre "getInstance()".
En clair je souhaite faire ceci.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
TMaclasse=class
 private
  ///Redéfinition du constructeur de classe
  constructor create();reintroduce;
 public
  ///Crée une seule instance de TMaclasse ou renvoie celle déja créée
  class function getInstance():TMaClasse;
  .....
end;

Mon problème est-que le constructeur create() reste visible en dehors de l'unité contenant TMaclasse.
Quelqu'un a une idée de comment je peux faire ça?...ou est-ce possible de changer la visibilité de mon constructeur;
Je précise que je suis sous Delphi 2005.

Merci

[samaury]

Dans le même ordre d'idée : est-il possible de changer la visibilité du destructeur pour le rendre inaccessible hors de mon unité?
Merci.

[Cl@udius]

Salut

J'ai besoin de changer la visibilité de mon constructeur de classe pour le mettre en "private" ou "protected"

Pourquoi ce besoin impérieux ?

La définition d'une classe Singleton n'est pas très compliquée en elle-même. Contrôler l'unicité de l'instance de la classe ne nécessite pas a priori de changer la visibilité du constructeur/destructeur.

@+ Claudius.

[samaury]

Pourquoi ce besoin impérieux ?

Je ne serai pas le seul à utiliser cette classe. Il s'agit d'une classe utilitaire que d'autres collègue auront à utiliser. Mon but est de les obliger à utiliser le getInstance() plutot que un create() pour instancier la classe.

La définition d'une classe Singleton n'est pas très compliquée en elle-même. Contrôler l'unicité de l'instance de la classe ne nécessite pas a priori de changer la visibilité du constructeur/destructeur.

Je suis bien d'accord. Mais pour la raison exposée plus haut masquer le create() me paraissait plus "propre" mais si ce n'est pas possible, je me contenterais de mon getInstance() sans masquer le create()
Merci

[Cl@udius]

Mon but est de les obliger à utiliser le getInstance() plutot que un create() pour instancier la classe.

Mouais. Je suis peut-être trop conventionnel.

Perso je définirais ma classe ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
interface
 
type
  TSingleton = class
  strict private
    class var
      FInstance: TObject;
      FRefCount: Integer;
  private
      FList: TList;
      F1: Integer;
  public
    destructor Destroy; override;
    class function NewInstance: TObject; override;
    procedure FreeInstance; override;
    class function RefCount: Integer;
  end;
 
implementation
 
{ TSingleton }
 
destructor TSingleton.Destroy;
begin
  FList.Free;
  inherited;
end;
 
procedure TSingleton.FreeInstance;
begin
  Assert(FRefCount > 0);
 
  Dec(FRefCount);
  if FRefCount = 0 then
  begin
    FInstance := nil;
    inherited;
  end;
end;
 
class function TSingleton.NewInstance: TObject;
begin
  if not Assigned(FInstance) then
  begin
    FInstance:= inherited NewInstance;
    FRefCount := 0;
    // Init des variables privées
    with TSingleton(FInstance) do
    begin
      FList := TList.Create;
      F1 := 0;
    end;
  end;
  Result := FInstance;
  Inc(FRefCount);
end;
 
class function TSingleton.RefCount: Integer;
begin
  Result := FRefCount;
end;
 
 
// Utilisation
 
var
  o1, o2, o3: TSingleton;
begin
  o1 := TSingleton.Create;
  o2 := TSingleton.Create;
  o3 := TSingleton.Create;
  ShowMessage(Format('RefCount: %d', [TSingleton.RefCount]));
 
  o1.Free;
  o2.Free;
  o3.Free;
  ShowMessage(Format('RefCount: %d', [TSingleton.RefCount]));
end;

Une instance unique de la classe avec un comptage de référence.
Cela me parait plus "conventionnel" voire plus simple.

@+ Claudius

[Kaféine]

Salut,

Plutôt que masquer le create, autant raisé une exception dedans.

Voici mon idée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
  TTest = class sealed
  private
    class var
      FCanCreate: Boolean;
      FInstance: TTest;
  public
    constructor Create;
    class function GetInstance: TTest;
  end;
 
implementation
 
constructor TTest.Create;
begin
  if not TTest.FCanCreate then
    raise Exception.Create('Utilisez la méthode GetInstance sinon je vous tire les oreilles :)');
end;
 
class function TTest.GetInstance: TTest;
begin
  if FInstance = nil then
  begin
    TTest.FCanCreate := True;
    FInstance := TTest.Create;
    TTest.FCanCreate := False;
  end;
  Result := FInstance;
end;
 
initialization
 
finalization
  if TTest.FInstance <> nil then
    TTest.FInstance.Free;

[samaury]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Mouais. Je suis peut-être trop conventionnel.

J'ai pas tout compris mais on va dire que on est lundi et que mon neurone n'est pas encore sorti d'hibernation...

Perso je définirais ma classe ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
...
  strict private
    class var
      FInstance: TObject;
      FRefCount: Integer;
...

J'ai peur que les appli win32 ne supportent pas le

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
strict private
    class var

comme déclaration à l'intérieur d'une classe, à moins que ce soit D2005...ou alors je m'y prends vraiment très mal.
Du coup mon équivalent de ton "FInstance" est déclaré dans la partie implementation de mon unité pour n'être accessible que localement.
Merci

[samaury]

if not TTest.FCanCreate then
raise Exception.Create('Utilisez la méthode GetInstance sinon je vous tire les oreilles ');

C'est à peu de chose près ce que j'ai fais mais en plus...menaçant

[Kaféine]

plus menacant c'est quoi tirage de coucouniettes?

[Dr.Who]

utilise un TInterfacedObject :

utilisation :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
var
  MonObjet : IMonObjet;
begin
  MonObjet := TMonObjet.Create;
end;

déclaration :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
type
  IMonObjet = interface
    [{CTRL+G}]
    function GetInstance: IMonObjet;
 
    function GetA: integer;
    procedure SetA(value: integer);
 
    property A : integer read GetA write SetA;
  end;
 
  TMonObjet = class(TInterfacedObject, IMonObjet)
  private
    fA : integer;
    function GetA: integer;
    procedure SetA(value: integer);
  public
    function GetInstance: IMonObjet;
  end;

explication :

on utilise l'interface et non l'objet (IMonObjet donc).
dans l'interface, il n'y a pas de constructeur, ni de destructeur (contrairement à TMonObjet).
seul donc les méthodes de IMonObjet apparaitrons.

[samaury]

Solution intéressante, je vais la creuser.
Si je comprends bien la definition de TMonObjet devra être masquée dans le "implementation" (de mon unité par exemple).

Par contre j'aurais mis le GetInstance() dans une classe utilitaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
TToolClass=class
public
  class function GetMonObjetInstance():IMonObjet;
end;
.
.
.
class function TToolClass.GetMonObjetInstance():IMonObjet;
begin
//...tests d'unicité de TMonObjet
  Result :=IMonObjet(TMonOjet.Create());
end;

Merci

[Kaféine]

Salut,

L'usage d'une interface est effectivement une bonne solution pour masquer l'implémentation.

Solution intéressante, je vais la creuser.
Si je comprends bien la definition de TMonObjet devra être masquée dans le "implementation" (de mon unité par exemple).

Tu comprends bien

Voici un exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
 
(...)
type
  IOutils = interface 
    function AjouteEntier(E1, E2: Integer): Integer;
    (...)
  end; 
 
function Outils: IOutils; //fonction renvoyant la boite à outils
 
implementation
 
var
  GOutils: IOutils = nil;
 
type
  TOutils = class(TInterfacedObject, IOutils)
  private
    function AjouteEntier(E1, E2: Integer): Integer;
  public
    constructor Create;
  end;
 
function Outils: IOutils;
begin
  if GOutils = nil then
    GOutils := TOutils.Create;
  Result := GOutils;
end;
 
{ TOutils }
 
function TOutils.AjouterEntier(E1, E2: Integer): Integer;
begin
  // cette fonction déchire grave :)
  Result := E1 + E2;
end;
 
constructor TOutils.Create;
begin
  // Logique du constructeur ici
end;
 
end.

[samaury]

Tu comprends bien

Me voila rassuré
Merci

[e-ric]

Salut

L'implémentation du singleton si l'on veut être formel n'est pas simple avec Delphi (je ne parle pas de la version .NET, je ne la connais pas).

Le constructeur ne peut être privé car Create est toujours disponible depuis TObject et on ne peut pas réduire la portée d'une méthode. En outre, Delphi a ce petit défaut qu'il est toujours possible pour un développeur de libérer l'objet à tout moment.

Pour le singleton, j'ai trouvé une solution "exotique" qui consiste à employer une classe et non un objet. Les méthode sont alors des méthodes de classe. L'état de "l'objet singleton" est représenté par des variables d'implémentation de son unité. Cela n'amène pas à un travail surhumain. Mais la solution a ses limites, l'état du singleton est en dehors (variables d'implémentation) de l'entité syntaxique utilisée, il n'est pas possible par exemple d'examiner l'état interne de ton objet grâce à un pointeur.

C'est un peu de la bidouille, mais du fait de l'emploi d'une classe, on obtient bien un singleton. Chaque classe est unique par nature.
Cependant si ton singleton

Cdlt

[samaury]

Merci pour ta remarque.
J'ai implémenté la solution du Dr Who basée sur l'utilisation d'interface.
Ca correspond bien à ce qu'il me fallait.
@+