Regras de negócio envolvendo valores

Vc pode verificar a melhor forma de fazer desta seguindo os seguintes passos

1. Os valores podem mudar constatemente - melhor fazer no bd

2. Se os valores não mudam - faça um atributo na classe

Eu não acho necessario ter um classe apenas para controlar isso, mais se vc for utilizar bd faça uma tabela status que fica mais facil de controlar

Eu não entendi muito bem seu problema mas se você precisa de constantes de um intervalo (como estados possíveis) acho que pode usar um enum.

pode usar um enum, do tipo:

public enum StatusArtigo
        {
		REVISAR(1),
		APROVADO(2),
		REJEITADO(3);
		
		private final int value;
		
		private StatusArtigo(int value) {
			this.value = value;
		}
		
		public int getValue() {
			return value;
		}
	
		public String toString() {
			return super.toString() + "(" + value + ")";
		}
	}

Tambem seria interessante usar uma estrutura do tipo

class Artigo {
   private StatusArtigo status;

   public void setRevisar() {
       this.status = StatusArtigo.REVISAR;
       /* Outras regras relacionadas a mudança de status poderiam
       entrar aqui*/
   }

O que eu acho feio é que no banco de dados vamos ter uma tabela de status. O enum é um espalho desta tabela. Beleza. Mas quando a tabela mudar? Tenho que recompilar o código. Isso não contraria os princípios de oo? Seja pra alterar o valor, o nome, adicionar ou excluir status?

Se sua tabela no banco mudar, retirando ou adicionando status por exemplo, acho bastante improvável que você não tenha que alterar nenhuma regra de negócio em seu código fonte, o que por si só já lhe obrigaria a recompilar o código. Não vejo onde isto afeta os pricípios de OO.

Também exis uma outra maneira de resolver que seria implementar as regras de negócio afetadas pelo status em uma classe que representasse este status. Dê uma olhada no pattern State: http://weblogs.java.net/blog/ryano/archive/2005/01/implementing_th_1.html

gostei deste design pattern!
porem acho que pra ele funcionar comigo o enum teria que ter conhecimento da classe artigo, um relacionamendo bidirecional

mzugaib:

gostei deste design pattern!
porem acho que pra ele funcionar comigo o enum teria que ter conhecimento da classe artigo, um relacionamendo bidirecional

Provavelmente não é o que você precisa então. Enum não é um design pattern, é um construto da linguagem, mas leia sobre o Pattern State.

pcalcado:

mzugaib:

gostei deste design pattern!
porem acho que pra ele funcionar comigo o enum teria que ter conhecimento da classe artigo, um relacionamendo bidirecional

Provavelmente não é o que você precisa então. Enum não é um design pattern, é um construto da linguagem, mas leia sobre o Pattern State.

Mas eu estava falando do State que faz uso de Enum! O que eu quis dizer é que acho que nos métodos equivalentes ao “Turn on” e “Turn off” eu teria que passar Artigo ou no próprio construtor do Enum? ? ou seja, o Enum ter conhecimento da classe Artigo.

Desculpe, eu ainda não entendi direito o que você quer fazer. Para mim, no seu post inicial você queria fazer algo como:

class Artigo{
 private Status status = Status.A_REVISAR

 public Artigo(Autor autor){
   if(autor.isGraduado()) status = Status.PUBLICADO;
 }
}

enum Status{A_PUBLICAR, PUBLICADO}

E se você precisa guardar o estado deste enum numa tabela pode fazer algo como o andreymb mostrou para ter um valor no enum, que é o armazenado na tabela.

Se a enum ficar em um assembly separado,

você pode recompilar somente o assembly dele, que pode ser mantido debaixo de uma interface o que não ocasionaria

grandes transtornos, inclusive dependendo do tamanho da aplicação podes começar a utilizar versionamento de assemblys.

confira o meu blog que está iniciando agora =D.