Discussion :

[olive_le_malin]

Bonjour à vous,
je dois écrire 2 classes A et B qui ne doivent avoir qu'une seule instance.
A doit pouvoir accéder à tous les membres de B, sans en dériver. (A contient un B ; A ne dérive pas de B)
B ne contient que des champs, elle n'a pas vraiment de fonctionnalités (c'est plutôt une classe de ressurces)

Donc pour le moment, j'ai fait :

A : classe singleton
contient un B*

B : classe singleton
Tous les membres de B en public pour que A puisse y accèder.
En effet si je déclare A amie de B, je risque de perturber mon implémentation singleton de B à partir de A, car A risquerait de pouvoir accéder au constructeur privée de B.

Mais je trouve ça un peu pourri ...

Comment vaut-il mieux procéder ?

[Laurent Gomila]

Est-ce que B doit être utilisée par autre chose que A ?

[olive_le_malin]

non.
Tu pensais à intégrer directement B dans A, non ? (c'est à dire à faire disparaître B?)

[coyotte507]

je dis peut être une bétise, mais on pourrait donner une variable statique à B:

Code :

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

1
2
3
4
5
6
//B.hpp
class B
{
  static bool wasInit;
  ...
};

dans le cpp de la classe B on fait:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
//B.cpp
static bool B::wasInit = 0;
 
B::B()
{
  //si déjà une instance
  assert (wasInit != 1)
  wasInit = 1;
 
  ...
}

Comme ça on ne pourrait créer qu'une seule instance de B.

[Laurent Gomila]

Tu pensais à intégrer directement B dans A, non ? (c'est à dire à faire disparaître B?)

Oui, éventuellement. Mais bon si les rôles sont bien séparés, garder deux classes distinctes restera plus clair. Dans ce cas, personnellement je ferais de B une classe privée imbriquée dans A, et non singleton.

[olive_le_malin]

Coyotte : le problème n'est pas dans la réalisation du singleton mais plutôt dans les rôles et des 2 classes.
Sinon ta conception assure que oui il n'y aura qu'une seule instance de B, mais elle n'interdit pas d'appeler son constructeur pour essayer d'en créer de nouvelles. C'est tout l'interêt du singleton qui ne déclare qu'une seule instance, statique.

Laurent :

Mais bon si les rôles sont bien séparés, garder deux classes distinctes restera plus clair.

Oui, c'est exact.

je ferais de B une classe privée imbriquée dans A

OK, je vais voir ce que ça donne.

Valefor :

C'est pas indispensable d'avoir un singleton de B je pense.

Ben pour mon architecture, on en doit avoir qu'un seul B.
Aprés que B soit singleton, ou classe privée imbriquée dans A comme le propose Laurent, ou autre .. là est la question.


MERCI

[rikau2]

Code :

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

1
2
3
4
5
6
//B.hpp
class B
{
  static bool wasInit;
  ...
};

Code :

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

1
2
3
4
5
6
7
8
9
//B.cpp
static bool B::wasInit = 0;
B::B()
{
  //si déjà une instance
  assert (wasInit != 1)
  wasInit = 1;
  ...
}

Comme ça on ne pourrait créer qu'une seule instance de B.

Ce genre de declaration fait, je pense, qu'appeler une methode qui ne possedera pas l'accesseur a B te permettant de savoir reelement si "wasInit" est different de 1.

Une technique a adopter dans ces cas la peut etre de faire un manager qui fait les appels a tes constructeurs de A et de B et qui possede en plus la partie logique de gestion
Classe C qui ne derive ni de A ni de B mais qui est capable de stocker toutes les instances (pointeurs) de A et de B et donc de faire des "stats" sur l'utilsation de tes classes. Le manager revient a une vulgaire BDD dans laquelle tu stockes l'ensemble des infos dont tu as besoin.

[befalimpertinent]

B ne contient que des champs, elle n'a pas vraiment de fonctionnalités (c'est plutôt une classe de ressurces)

Juste pour info.
Lorsqu'une classe ne contient que des champs. Une bonne manière est, je pense, d'en faire un struct. Je sais que ça ne change pas grand chose niveau implémentation mais disons que c'est plutôt une question d'ordre philosophique.

[befalimpertinent]

Sinon pour répondre plus à ta question. Imbriqué B dans A comme le suggérait Laurent me semble une bonne idée

[olive_le_malin]

Bonjour,
en effet ça m'a l'air pas mal, je vais faire comme ça (et en struct éventuellement ... )

PAr contre : comme je l'ai vu dans d'autres posts, le compilo ne va-t-il pas interpreter tout ça comme un simple friend ?

[rikau2]

Juste pour donner mon avis...

Lorsque l'on fait de la prog c++, il faut eviter les struct et preferer la declaration dans une classe au pire en public, mais l'interet est de permettre une evolutivite du systeme un peu plus tard sans avoir a refaire la structure. Je parle en connaissance de cause ...

Dans mon projet actuel, trois struct ont ete implementee, d'aspect basique, mais lorsqu'il a fallu ajouter des verifications sur les valeurs stockées dans la struct.... la c'etait plus galere. Mieux vaut un bon fichier header avec la description de ta classe, sans cpp dans un premier temps si il n'y a pas de methodes, mais au moins, un fichier par classe, une possibilité d'évolution simplifiée

[Laurent Gomila]

PAr contre : comme je l'ai vu dans d'autres posts, le compilo ne va-t-il pas interpreter tout ça comme un simple friend ?

Comment ça ?
Le seul effet que cela va avoir est que seule la classe A aura connaissance de B. Les amis de A aussi, mais si ça pose problème ça peut s'arranger facilement.

[olive_le_malin]

Par contre, comment est assurée ma contrainte d'unicité de B ?