Nous utilisons un «cadre d'état» (basé sur le modèle d'état) qui n'expose pas son état actuel, ce qui signifie parfois que je dois faire les choses de manière rond-point.
Lorsque j'ai interrogé cette décision de conception, l'une des justifications était que "si vous devez connaître l'état actuel, tu l'utilises mal".
est-ce correct? Je ne suis pas une grande partie d'un expert sur les machines d'état.
(Je demande ici parce que je sais que j'ai un biais inhérent contre le modèle d'état, que je trouve trop verbeux.)
exemple
Imaginez un système qui dans l'un d'entre eux lit deux capteurs. Un capteur donne une valeur numérique, l'autre donne un booléen qui vous indique si le premier est «fiable» ou non. Le système génère une valeur qui est la "bonne" valeur actuelle ou une interpolation (ou un autre calcul de fantaisie) basée sur les dernières valeurs n .
Mon idée serait d'avoir deux sommets - un "bon", l'autre "pas". Et quand une nouvelle valeur arrive, j'aimerais demander à la machine d'état qui indiquait que c'est que je sache comment gérer l'interpolation.
(Je pense avoir répondu à ma propre question: la solution serait d'avoir un événement NewdataValue (VAL) dans la machine à états, qui ne ferait que transmettre la valeur du "bon" état ?)
4 Réponses :
Eh bien, c'est la vraie question. Pourquoi avez-vous besoin de connaître l'état actuel de la machine à états? Que comptez-vous faire avec cela?
Si vous êtes deuxième, essayez de prédire l'endroit où la machine d'état sera à l'avenir basée sur l'état actuel et les nouvelles entrées, vous utilisez également quelque chose en parallèle à la machine à états. Dunno, que ce soit bon ou mauvais, cela dépend de quoi et pourquoi vous le faites.
ostensiblement, la machine d'état est une boîte noire (ou dans certains cas, semble être une machine à sous!) que vous nourrissez des données pour et tirez des données de.
Comme quoi que ce soit dans la programmation, il n'y a pas besoin de choses comme des boîtes noires opaques. Les choses peuvent toujours être des boîtes de boîtes transparentes qui ont des emplacements d'entrée et des emplacements de sortie, mais vous pouvez au moins voir les engrenages à l'intérieur d'eux. Mais il est compteur à l'abstraction si vous essayez de le contourner, car la machine d'état est conçue pour encapsuler un bloc de logique.
Donc, l'opacité de la structure n'est pas vraiment la question, c'est ce que vous essayez de faire avec les informations si ou lorsque vous l'obtenez.
J'ai bien peur de devoir être en désaccord avec "il n'y a pas besoin de choses comme des boîtes noires opaques". Cela conduira invariablement à la fuite d'informations et aux personnes qui comptent sur cette information. C'est les mêmes personnes qui vous retrouveront et qui vous battront à mort lorsque vous essayez de rendre votre code plus efficace, rompant cette fuite qu'elles sont venues dépendre de. Vous n'avez pas jamais apportez des informations disponibles en dehors d'une structure de données, sauf si vous souhaitez être enfermé pour le soutenir pour toujours.
Ce n'est pas parce que le processus est ouvert à l'inspection ne signifie pas que cela doit être corrompu. Votre contrat est explicite, la mise en œuvre pourrait bien fournir une lumière sur ce contrat, mais elle ne rend pas le contrat inviolée. Si d'autres essaient de violer ce contrat, c'est leur problème. Vous aimerez peut-être mener votre entreprise dans une pièce sombre, verrouillée et fumée. Je préfère plus de soleil sur le mien. Je préfère un gril ouvert pour que je puisse voir la nourriture faite. Je préfère faire confiance à mes utilisateurs que de les verrouiller à cause de ce qu'ils pourraient faire. Je suppose que vous choisissez de ne pas faire confiance à la tienne.
Je dois être d'accord avec la personne qui a fait le commentaire "Utiliser le problème".
Le point entier d'une machine d'état doit être une boîte noire dans laquelle les événements sont pompés et qui causent certaines choses sur la base de ces événements (y compris les transitions de l'État). Les événements eux-mêmes ne doivent pas dépendre du tout sur l'état actuel de la machine.
Je ne peux pas envisager une seule situation dans laquelle l'événement devrait changer en fonction de l'état actuel (mais de la peine Gratuit de m'éclairer si vous en avez un). Un événement toujours est ce qu'il est. S'il doit être traité différemment basé sur l'état actuel, c'est-à-dire un problème pour la machine d'état elle-même, pas la pompe d'événement. En fait, toute l'idée de changer Un événement basé sur l'état actuel vole face à l'encapsulation. Les meilleures machines d'état ont une forme très simple: en d'autres termes, Les événements sont pompés en quelque sorte (indépendamment de l'état) et ont certains effets basés sur son état et les événements. Et il maintient son propre état. en termes de mise à jour de votre question où vous souhaitez gérer la sortie différente selon que la dernière lecture était bonne ou une formule basée sur les précédentes, Je voudrais juste mettre cela dans la section des effets. Demandez à la machine à états la valeur actuelle plus une indication sur la question du capteur ou calculée. alors votre code qui gère les effets peut faire ce qu'il aime avec ça informations. Cela vous donne effectivement les informations dont vous avez besoin et ne casse pas la nature noire.
J'avais un exemple (voir ma question mise à jour), mais je pense que je l'ai répondu moi-même :)
"Si vous devez connaître l'état actuel, vous utilisez le problème". - C'est correct.
L'état actuel ne peut pas être exposé. Toutes les choses qui vous obligent à agir différemment, en raison d'être dans l'état déterminé, doivent être placées à l'intérieur ( et là-bas là-bas ) de cet état - comme méthodes privées appelées de celles publiques, ou comme publique, faire rien (ou autre chose) dans d'autres États. Votre "machine d'état" doit fonctionner ... et vous, à la recherche de l'extérieur, je ne devrais pas savoir pourquoi.
Dans la conception de systèmes hiérarchiques Habituellement, l'objet niveau supérieur ne connaît que l'abstraction de l'état de l'objet de niveau inférieur. État_good abstraction (parfait, acceptable, ...) et stat_bad abstraction (échec1, échec2, échec3 ..).
Dans les systèmes non hiérarchiques, il est correct pour un objet de savoir précisément l'état d'un autre objet, en particulier si des objets sont attribués des tâches différentes.
-Janusz