Comme vous l'avez sans doute pu le lire, la Conception de l'État, Modèle est utile lorsque l'état varie selon le comportement de certains objets dont la composition comprend cet état. Cela implique l'idée d'un State classe abstraite, interface, ou d'un type énuméré - même en fonction de la langue Duck-Typing va faire aussi bien que définit toutes les communes de comportement et/ou de méthodes requises.
Les Principaux Aspects
Il y a vraiment deux principaux aspects à prendre en compte dans le travail avec l'état de motif: l'énumération et de la transition. L'énumération signifie simplement l'identification de l'ensemble des états possibles (par exemple, les jours de la semaine), ou de manière plus abstraite les types d'états (notamment les méta unis) telles que le début, la fin, et entre les deux pour un moteur de workflow.Transition signifie décider comment le modèle de circulation entre les etats où cela est généralement fait en capturant toutes les transitions possibles dans une représentation sous forme de tableau (c'est à dire Finite State Machine) ou de faire de chaque etat connaître son éventuelle "transitions" à d'autres états.
Généralement, les transitions vont main dans la main avec les méta-états-unis parce que ce n'est pas possible de connaître tous les états et les relations à l'avance dans un tel système dynamique où les nouveaux etats, et donc les transitions, peuvent être ajoutés lors de l'exécution. En outre, avec l'approche de transition, certains comportements - les notifications par exemple - devient partie intégrante de la transition, au lieu de l'état lui-même.
Exemples
Il y a plusieurs scénarios, j'ai travaillé sur ou discuté où c'est une installation d'usage:
- Flux de travail
- Ordinateur De Jeu De L'Adversaire A. I.
- L'Orchestration Des Processus
Par flux de travail , je veux dire quelque chose comme jBPM. De tels systèmes sont concernés par le commandant de la droite attention, des bonnes personnes, au bon moment. Ils ont l'habitude de l'envoyer beaucoup de courriels ou de quelque autre sorte de notification. Et, les processus qu'ils représentent les besoins de la capacité à changer à mesure que l'organisation change, alors que les données gérée généralement des modifications beaucoup plus lentement.
Ordinateur de Jeu de l'Adversaire A. I. est auto-explicatif. Pas quelque chose que j'ai écrit, mais dans la conversation avec ceux qui ont, ces systèmes sont généralement autonomes. En d'autres termes, à la différence de flux de travail, le jeu n'a généralement pas la possibilité de modifier le processus utilisé pour contrôler les adversaires d'ordinateur.
L'Orchestration des processus est similaire à flux de travail, tout en mettant l'accent sur l'intégration du système, au lieu de personnes de l'interaction. L' Apache Mule cadre en est un exemple. Ici, l'état peut décrire l'état (par ex. commencé, en cours, terminé) et le type (par exemple, ftp point d'intégration, intégration de sql point).
Conclusion
Contrairement à d'autres réponses, je pense que l'état d'encapsulation est un excellent moyen de gérer le changement dans les systèmes logiciels. Bien fait, il facilite ces changements ou permet aux utilisateurs de le faire au moment de l'exécution. Vous faites un compromis de plus de flexibilité en échange de l'augmentation de la complexité de mise en œuvre. Si une telle approche n'est probablement pas utile pour le panier par exemple, si le comportement est probablement très bien connue et n'est pas à modifier. En revanche, lorsque le processus est sujet à changement, il fait un très bon ajustement.
