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

[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.
@+