Ao aplicar o pattern state nós criamos as classes que representam os estados, porém para alterar o estado do orçamento tivemos que implementar o método public void setSituacao(SituacaoOrcamento situacao) {
this.situacao = situacao;
}.
Esse método não cria um problema no fluxo dos estados já que abre a opção de usar o setSituação em vez de usar os métodos Aprovar ou Reprovar, fazendo assim com que os fluxos sejam quebrados ? Por exemplo, eu poderia fazer com que um orçamento já reprovado fosse aprovado chamando o método setSitucao(new Aprovado()) diretamente. Existe alguma forma que não é possível isso acontecer ?
Solucionado (ver solução)
Solucionado
(ver solução)
2
respostas
respostas
Pattern State
solução!
Oi Iago,
Sim, tem essa questão de ter o método setSituacao, que nada impede de alguem o chamar diretamente.
Uma alternativa de impedir isso seria alterando a estrutura de pacotes da aplicação de packages by layer para packages by feature, e alterando a visibilidade do método setSituacao para package private e com isso apenas as classes do mesmo pacote podem enxergar e chamar o método.
Nem sempre vai dar para utilizar os patterns sem "quebrar" algum princípio da orientação a objetos e/ou do SOLID. Vale então avaliar as vantagens/desvantagens de cada solução adotada.
Bons estudos!
Iria levantar o mesmo ponto.