Como pegaria o estado do state para usar em banco de dados

Você está certo, mas imagine que temos uma situação em que precisamos executar lógicas de negócio que dependem do estado do objeto. Nesse caso, com a sua solução utilizando uma enum simples, teríamos que colocar um if para cada estado que foi criado no projeto.

Se o número de estados for muito grande, seu código vai acabar ficando extenso e difícil de ser entendido por causa do número de linhas.

Lembre-se que os design patterns não são soluções absolutas para os problemas, eles são apenas sugestões de soluções que podem ser aplicados para determinados tipos de problema.

Oi Quilmer,

Veja só que no seu exemplo, o "estado" armazenado parece ser apenas uma informação da entidade, assim como "endereço", por exemplo. Nesses casos, o enum resolve.

Agora, como o Victor disse, se o comportamento da entidade variar de acordo com o estado, o State pode ser uma boa maneira de se evitar código complicado e cheio de if's.

E, como ele também disse, lembre-se que padrões de projeto são sugestões de soluções, e devem ser usadas com parcimônia.

Sim isto eu compreendi, e State no meu ver deve ser usado quando o estado dita a regra e impõe condicionais crescentes.

Ainda não fui pro segundo curso de design patterns, mas acredito que o padrão Factory poderia ser usado para instanciar corretamente os estados que vem do banco, sem que nossa classe "principal" tenha que instancia-los e ter que conhecer os códigos de estados.

Oi Gustavo,

É isso aí! Não tem como fugir, alguém vai ter que conhecer os estados, pra instanciá-los, certo? Talvez um pouco de reflection ajude e tal, mas a boa ideia é esconder essa lógica numa classe que só faz isso! Ou seja, uma factory! No curso 2, vc vai ver! :)