++
Pour moi ca ressemble à un cas d'école du DP Etat.
Version imprimable
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:
1
2
3
4 #include "BanksysXenteoRAII.h" #include <windows.h> extern CBanksysXenteoRAII banksysXenteoRAII;
Fichier stdafx.cpp:
Code:
1
2
3 #include "stdafx.h" CBanksysXenteoRAII banksysXenteoRAII;
Fichier Winmain.cpp:
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.Code:
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; }
J'ai du mal à définir les états, suis pas encore habitué des designs pattern :oops:
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.
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.
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.
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.