Discussion :

[tiagocerqueira]

Bonjour,

Ma question est la suivante, je voudrai que dans une classe A je ne puisse qu'instancier qu'une seul fois une autre classe B.

Cependant je voudrai que si je recrée une classe A, je puisse tout de même reinstancier la classe B.

Est ce que le modele singleton permet de faire ca?? sinon comment faire?

[LittleWhite]

Je ne suis pas sur d'avoir compris la question.

Si la nouvelle classe A est crée, il faut que B soit nouveau, ou que B soit le même que dans la première classe A.
Certes un singleton sur B, ça peut aider, mais ne serait-ce pas tout simplement une variable static?

[3DArchi]

Salut,
Pareil. Je ne suis pas sur d'avoir compris la question. A priori, j'ai l'impression que le singleton n'est pas la solution. Mais j'hésite entre la variable de classe ou la variable membre tout court !

[tiagocerqueira]

Bonjour,

je vais essayer de tout expliquer:

j'ai un programme qui a pour but de dialoguer avec un automate, et je desire encapsuler ma requete et ma réponse dans une seul et meme classe A. j'utilise donc le pattern factory qui me permet de créer ma requete et ma reponse à un l'instant que je le désire (au moment ou je reçois la réponse). ca c'est fais et ca fonctionne.

Le soucis est que rien ne m'empeche dans ma classe de créer plusieur réponse. et ca je ne le veux pas, je veux uniquement 1 requete et 1 reponse dans ma classe A. cela signifie que je dois créer un mécanisme pour éviter la double instanciation de ma classe requete et reponse.

J'ai pensé à une variable static, mais je ne trouve pas ca élégant. y a il une autre solution, merci.

[nikko34]

Si tu restes dans la classe A.. ben euh c'est la classe A qui décide de ce qu'elle fait non? Si elle considère qu'il n'y a qu'une requête et une réponse ben... qu'elle ne fasse qu'une requête et qu'une réponse?

Si la classe A offre la possibilité à un client exterieur de faire des requête/réponse, ben pareil, c'est la classe A qui doit gérer ça en interne?

Ou j'ai pas compris un truc?

[3DArchi]

Effectivement, je ne vois pas trop le besoin du singleton. Associer une requête et une réponse (par exemple dans un bête std::pair) peut représenter une transaction.

[bretus]

Bonsoir,

En somme, Singleton c'est pratique, mais faut pas essayer d'en mettre partout. Sans être catégorique, tu peux adopter un singleton lorsque tu as besoin d'une unique instance d'une classe et d'un accès global à cette instance...

Bye

Notes :
- Ta fabrique peut assurer la création d'un unique objet. En terme de design pattern, ça serait plutôt un "pool" je crois.
- Le singleton est très dangereux, au sens où c'est difficile de s'en séparer lorsque l'on refractor.

[3DArchi]

Salut,

Notes :
- Ta fabrique peut assurer la création d'un unique objet. En terme de design pattern, ça serait plutôt un "pool" je crois.
- Le singleton est très dangereux, au sens où c'est difficile de s'en séparer lorsque l'on refractor.

Sur le singleton, je crois qu'avant de l'utiliser lire ce genre d'article est indispensable