Discussion :

[3DArchi]

La connexion peut être persistante d'une transaction à l'autre, donc ça a du sens d'encapsuler ça dans un objet.

La méthode processTransaction ne faisant qu'ouvrir la session et la fermer, tout en gardant la connexion.

Pas vraiment besoin de RAII, cela dit.

++
Pour moi ca ressemble à un cas d'école du DP Etat.

[Lavock]

La connexion peut être persistante d'une transaction à l'autre, donc ça a du sens d'encapsuler ça dans un objet.

Au temps pour moi !

Pour moi ca ressemble à un cas d'école du DP Etat.

Et encore... On a une ressource (critique ?) et deux état...

[Trunks]

Mais alors, pourquoi une classe ? Au pire, un vielle objet purement statique si tu y tiens... m'enfin, le truc que tu nous décris, ça ma beaucoup plus l'air purement procédural...

L'intéret est de créer une DLL qui permet de piloter très simplement le lecteur bancaire. Avec la DLL que je viens de faire, l'utilisation dans le programme de la borne est simplissime:

Fichier stdafx.h:

Code :

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

1
2
3
4
#include "BanksysXenteoRAII.h"
#include <windows.h>
 
extern CBanksysXenteoRAII banksysXenteoRAII;

Fichier stdafx.cpp:

Code :

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

1
2
3
#include "stdafx.h"
 
CBanksysXenteoRAII banksysXenteoRAII;

Fichier Winmain.cpp:

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
#include "stdafx.h"
#include "BanksysXenteoRAII.h"
 
int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
	while (true)
	{
		MessageBoxA(NULL, "Veuillez insérer votre carte", "Message", MB_OK | MB_SYSTEMMODAL);
		bool bRet = banksysXenteoRAII.ProcessTransaction(2);
 
		if (!bRet)
		{
			MessageBoxA(NULL, "Echec de la transaction", "Message", MB_OK | MB_SYSTEMMODAL);
		}
		else
		{
			MessageBoxA(NULL, "Réussite de la transaction", "Message", MB_OK | MB_SYSTEMMODAL);
 
			break;
		}
	}
 
	return 0;
}

Et puis c'est tout, l'utilisateur de la DLL n'a même pas besoin de savoir comment c'est codé derrière. Il crée juste une instance de la classe CBanksysXenteoRAII, et applique la fonction ProcessTransaction() et teste la valeur de retour pour savoir si la transaction s'est bien déroulée ou non.

Pour moi ca ressemble à un cas d'école du DP Etat.

J'ai du mal à définir les états, suis pas encore habitué des designs pattern

Tu peux me détailler un peu plus stp car l'exemple que tu m'avais donné n'est pas clair.


Note: Dans le cas concret, la borne est une application MFC, d'où l'initialisation de la DLL dans stdafx. Par ailleurs, j'ai supprimé le fonctionnement via l'envoie d'exception, sinon je n'aurais pas pu initialiser et utiliser la DLL dans des bouts de code diférents. J'utilise des variables internes pour tester la réussite ou l'échec des différentes étapes.

[Lavock]

C'est un pattern relativement simple selon les cas. Exemple :
Ton appli/objet et dans un états A. Sur un événement 1, elle passe à B. Sur un événement 2 elle passe à C.
Ton appli/objet et dans un états B. Sur un événement 3, elle passe à A. Sur un évènement 2, elle passe à C.

etc...

En gros, c'est applicable lorsque tu connais tout tes états et tes façon d'y passer.

Toi tu as décider de voir la connexion et la session comme des ressources. 3DArchi préfère les voir comme des états.

La principal question que tu dois te poser ces : que se passe t'il lorsque je ne libère pas ma ressource ? Si la réponse est : c'est pas grave => le RAII ne sert à rien.

Ici, de toute façon, tu ne peux pas gérer la session en RAII : elle ne vas pas de pair avec ton objet, ça durée de vie est plus courte. Ce n'est pas à toi de gérer cette ressource en somme.

[3DArchi]

C'est un pattern relativement simple selon les cas. Exemple :
Ton appli/objet et dans un états A. Sur un événement 1, elle passe à B. Sur un événement 2 elle passe à C.
Ton appli/objet et dans un états B. Sur un événement 3, elle passe à A. Sur un évènement 2, elle passe à C.

Oui et en gros, cela te permet de 1/mettre des actions sur les transitions et 2/ d'avoir un comportement différencié selon l'état courant.

Toi tu as décider de voir la connexion et la session comme des ressources. 3DArchi préfère les voir comme des états.

Peut être un vieux réflexe réseau/télécom : quand je vois OuvrirSession/Connecter/DemarrerTransaction, j'ai envie de sortir mon automate (soit, un DP Etat). Il y a certainement d'autres solutions mais je trouve que celle-ci présenterait probablement le plus de souplesse pour l'adapter à d'autres automates (tiens, tiens) de CB.