Discussion :

[bolo]

Bonjour,

je suis en train de créer un player j'utilise le design Etat. Pour l'instant j'ai 3 états
Play
Lecture
Pause.

Je suis en train d'implémenté le sound :
Stopper le son
Redémarrer le son
Défninir le son

Dois je créer 3 états ?
onSound
offSound et
setSound ?

Merci beaucoup

[Promeneur]

Qu'est-ce que tu appelles le design Etat ? Un diagramme d'état UML ?

Il me semble que pour l'instant, tu as trois états, ON , PAUSE et Off.

Je ne sais pas ce que veut dire « SetSound ». Régler le son ? Mettre en ON, Pause ou Off ? Dans ce cas, c’est plutôt une transition qu’un état.

[bolo]

Qu'est-ce que tu appelles le design Etat ? Un diagramme d'état UML ?

C'est ce pattern
http://en.wikipedia.org/wiki/State_pattern

Il me semble que pour l'instant, tu as trois états, ON , PAUSE et Off.

plus maintenant j'ai 2 autres états
offSound // Stop le son
et onSound // Démarre le son

Je ne sais pas ce que veut dire « SetSound ». Régler le son ? Mettre en ON, Pause ou Off ? Dans ce cas, c’est plutôt une transition qu’un état.

SetSound permet de régler le sound. pourquoi les deux états
offSound // Stop le son
et onSound // Démarre le son
ne sont pas des états ?

[Promeneur]

Je n’avais pas compris qu’il s’agissait du design pattern State.

Mais même comme cela, je trouve étrange que « Stopper le son » et « Démarrer le son » soient des états. Pourquoi pas, après tout. Mais il me semble plus naturel que dans l’état « Off », la commande qui du Player qui correspond à appuyer sur un bouton marche / arrêt, par exemple, lance la fonction qui va allumer le player (le faire passer à l’état ON) ; et qu’une fois à l’état ON, le même bouton appelle la fonction qui fait passer le player à l’état OFF. Cela ne nécessiterait que deux états (pour cet aspect du fonctionnement du Player).


Dans l'exemple donné ici (voir le code "real") http://www.dofactory.com/Patterns/PatternState.aspx , il y a des opérations comme "ajouter de l'argent" ou "retirer de l’argent". Chaque opération est implémentée différemment selon l'état, et une opération peut éventuellement provoquer un changement d'état. Mais les opérations ne sont pas des états.




Richard

[bolo]

Mais même comme cela, je trouve étrange que « Stopper le son » et « Démarrer le son » soient des états.

Il faudrait mieux faire des transitions ?

Mais il me semble plus naturel que dans l’état « Off », la commande qui du Player qui correspond à appuyer sur un bouton marche / arrêt, par exemple, lance la fonction qui va allumer le player (le faire passer à l’état ON) ; et qu’une fois à l’état ON, le même bouton appelle la fonction qui fait passer le player à l’état OFF. Cela ne nécessiterait que deux états (pour cet aspect du fonctionnement du Player).

Mon premier message est incorrect
J'ai 3 états
Start
Pause
Stop

Donc pour toi il serrait plus judicieux de faire des transitions. Donc j'aurais 3 nlles méthodes:

stopSound()
StartSound()
SetVolume()

C'est bien ca ?

Je dois aussi ajouter un méthode Record. Je pensais faire un état
comme cet exemple
http://www.adobe.com/devnet/flashmed...ne_as3_04.html
tu en penses quoi ?

[Promeneur]

Je n’ai pas lu tout l’article que tu donnes en lien, mais il me semble aller en mon sens. Mais il se peut que toi et moi ayons simplement un problème de définition.

L’idée est que tu as un certain nombre de commandes de bases, que l’utilisateur peut utiliser n’importe quand (même quand ce n’est pas approprié, comme appuyer sur Stop alors que le player est déjà stoppé).

Selon l’état de la machine, les commandes vont être implémentées différemment. Dans l’état OFF, la commande Stop sera implémentée différemment que dans l’état ON, ou que dans l’état Pause.


Dans le schéma exemple, tu as 5 états. Play aurait dû être appelé « Playing », parce que si tu regardes le code, tu vois que l’action startPlay dans l’état « Play » renvoie un message comme quoi le player est déjà en train de fonctionner. De même pour les 4 autres états, « Stop » ne veut pas dire en train de stopper, mais bel et bien "stoppé".

Donc oui, il te faut les transitions qui permettent de passer d’un état à l’autre. Par exemple la transition « Play » va permettre de passer de Stopped à Playing, si l’action est demandée dans l’état Stopped, et va renvoyer un message d’erreur si l’état est déjà Playing.

Et pour Record, pareil, tu as l'état "Recording" où le player est en train d'enregistrer, et la transition Record, qui doit être implémentée dans chaque état.


Richard

[koala01]

Salut,

Personnellement, je ne verrais bien que deux état: play et dontplay (running et notrunning, tu les nommes comme tu veux )... et trois transitions potentielles: start(), pause() (arret, sans perte de la position actuelle) et stop() (arret avec perte de la positon actuelle)...

Je ne sais pas, cela me semblerait plus logique que d'avoir trois état, là où deux suffisent amplement

Finalement, il n'y a qu'une chose qui importe quant à l'état: tu entend ou non...

La seule différence venant du fait que, si tu appuies sur "stop", tu abandonne la piste en cours de lecture, alors que si tu appuies sur "pause", tu garde bien préciseusement la position à laquelle tu est arrivé sur la piste de lecture en cours