|
O padrão State é motivado por aqueles objetos que, em seu estado atual, varia o seu comportamento devido as diferentes mensagens que possa receber.
Como exemplo, tomamos uma classe TCPConection que representa uma conexão de redeLivro, um objeto desta classe terá respostas diferentes, dependendo da seu estado(Listening, CloseDisponível o EstablishedPrestado). Por exemplo invocando o método Openreservar de um objeto da classe TCPConectionLivro seu comportamento será diferente, se ao conexãoLivro está no estado CloseDisponível o emno estado EstablishedPrestado.
[[File:TCPconexionLibroColorido3.pngjpg| 500pxcenter | Diagrama UML, TCPConexionejemplo Padrão State]]
== Problema ==
Há uma extrema complexidade no código quando tentartentamos gerirgerênciar comportamentos diferentes, dependendo de um número de estados diferentes. Também manter o código torna-se difícil, e mesmo em alguns casos, podem apontar para a uma inconsistência de estados atuais na forma de implementação dos diferentes estados no código (por exemplo, com variáveis para cada estado).
== Considerações ==
Se implementa uma classe para cada estado diferente do objeto e o desenvolvimento de cada método para cada estado em particular. O objeto da classe a que pertencem esses estados resolvem os diferentes comportamentos, dependendo de sua condição, com as instâncias das classes de estado. Assim, sempre está presente em um objeto o seu estado atual e se comunica com ele a resolvendo suas responsabilidades.
A idéia principal do padrão State é a introdução de um [[classe abstrata]] TCPStateEstadoLivro que representa os estados da conexão de rede e uma interface para todas as classes que representam os próprios estados. Por exemplo, as classes TCPEstablishedDisponível e TCPClosePrestado implementam responsabilidades especiais para os estados EstablishedDisponível e ClosePrestado respectivamente do objeto TCPConnectionLivro.
A classe TCPConnectionLivro mantém uma instância de alguma subclasse de TCPStateEstadoLivro com o atributo stateestado que representa o estado actual dado conexãoLivro. Na implementação dos métodos de TCPConnectionLivro haverá chamadas a esses objetos que serão representados pelo atributo stateestado para a execução das responsabilidades, dependendo de qual estado se encontre en esse momento, enviará essas chamadas para um objeto ou outro das subclasses de TCPStateEstadoLivro.
== Estrutura UML ==
== Os participantes ==
#'''Context (Contexto):''' Este integrante define a interface com o cliente. Mantém uma instância de ConcreteState (Estado Concreto) que define seu estado atual.
#'''State (Estado):''' Define uma interface para encapsular as responsabilidades associadas a um estado particular de contextcontexto.
#'''Subclasse ConcreteStateEstadoConcreto:''' Cada uma dessas subclasses implementa o comportamento ou responsabilidade de ContextContexto.
O Contexto (Context) delega o estado específico para o objeto ConcreteStateEstadoConcreto atual. Um objeto de ContextContexto pode passar-se como parâmetro a um objeto StateEstado. Assim, a classe StateEstado pode acessar o contexto, se fosse necessário.
ContextContexto é a interface principal para o cliente. O cliente pode configurar um contexto com objetos StateEstado. Uma vez feito isso, os clientes não têm de lidar com objetos de Statetipo Estado diretamente. Tanto o objeto de ContextContexto como os objetos de ConcreteStateEstadoConcreto podem decidir a mudança de estado.
== Colaborações ==
== Como funciona ==
A classe ContextContexto envia mensagens para os objetos de ConcreteStateEstadoConcreto dentro de seu código para dar a estes a responsabilidade que deve ser cumplida pelo objeto ContextContexto. Então, o objeto ContextContexto vai mudando as responsabilidades de acordo com o estado em que se encontra, devido a que também muda de objeto ConcreteStateEstadoConcreto ao fazer a mudança de estado.
== Quando usá-lo? ==
São as seguintes vantagens:
* É fácil de localizar as responsabilidades de estados específicos, devido a que os encontram nas classes que correspondem a cada estado. Isto proporciona uma maior clareza no desenvolvimento e na manutenção subsequente. Esta facilidade é fornecida pelo fato de que diferentes estados são representados por um único atributo (Stateestado) e não envolvidos em diferentes variáveis e grandes condicionais.
* Faz as mudanças de estado explícitas, posto que em otro tipo de implantação os estados são alterados, modificando os valores em variáveis, enquanto aqui fazer-se representar cada estado.
* Os objetos StateEstado podem ser compartilhados se eles não contêm variáveis de instância, isto pode ser alcançado se o estado está totalmente codificado representando seu tipo. Quando isso é feito, os estados são flyweights sem estado intrínseco.
* Facilita a expansão de estados.
* Permite a um objeto alterar de classe em tempo de execução dado que ao modificar suas responsabilidades pela de outro objeto de outra classe, a herança e responsabilidades do primeiro mudaram pelas do segundo.
== Conclusões ==
O padrão não indica exatamente donde definir as transições de um estado para outro. Há duas maneiras de contornar isso: Uma delas é definir essas transições dentro da classe ContextContexto, a outra é definir essas transições nas subclasses de StateEstado. É mais conveniente utilizar a primeira solução quando o critério a ser aplicado é fixo, ou seja, não mudará. O segundo é conveniente quando este critério é dinâmico, a desvantagem aqui é apresentada na dependência de código entre as subclasses.
Precisamos também avaliar a implementação ao criar instancias de estado concreto diferentes ou usar a mesma instância compartilhada. Isto irá depender se a mudança de estado é menos frequente ou mais frequente, respectivamente.
| 