Solucionado (ver solução)
Solucionado
(ver solução)
5
respostas

Situação estranha no Design Pattern STATE

Olá pessoal,

Interessante no exemplo o professor Maurício ter criado três métodos na classe base, a saber aprovado(), reprovado() e finalizado().

Estranho, porém, em minha opinião, é o fato de que nem sempre certas transições em nossa máquina de estado existem. Dai apenas lançar uma exceção ficou como a solução dele. Porém, me parece, pelo pouco que sei, um pequeno mau cheiro de código visto que é implementar algo desnecessário, ainda que pra apenas lançar uma exceção, fugindo portanto da responsabilidade da classe.

Soa coerente?

5 respostas

Olá Marcelo, tudo bem?

Realmente, isso pode ser considerado um mau cheiro de código, já que ele quebra o contrato da interface lançando uma exceção.

Uma implementação possível seria segregar mais as interfaces, o conceito de interfaces magras. Dessa forma, podemos ter uma interface apenas com um método, por exemplo, getState() e mais interfaces para cada um dos estados.

Olá Yuri,

Obrigado pelo input.

Você escreveu:

"Uma implementação possível seria segregar mais as interfaces, o conceito de interfaces magras. Dessa forma, podemos ter uma interface apenas com um método, por exemplo, getState() e mais interfaces para cada um dos estados."

Poderia dar-me um exemplo concreto, por favor ? VAleu.

Opa Marcelo, tudo bem?

Quando seus estados seguem uma ordem específica, você pode tentar seguir a ideia deste post.

Contudo, como no curso um estado pode ir para mais de um outro estado, é comum encontrarmos a abordagem que lança exceções. Já que, pensando bem, segregando em interfaces ficaria mais complexa a implementação. Para evitar que a exceção seja lançada, nosso sistema tem que tratar isso.

Oi Yuri,

Mas esse exemplo que você me passou parece muito mesmo com o Decorator

solução!

Olá Marcelo,

Alguns padrões de projeto tem implementações muito parecidas, o que muda é basicamente a finalidade do padrão, o motivo dele ser usado.