Argumento mais concretos/consistentes, Enum? Classe? Static?

Sim, enums.

dooda:

Olá pessoal,

Pode ser uma dúvida simples, mas dei uma procurada aqui no fórum no pai de todos os dúvidosos (google) e não achei nada interessante pra minha duvida, então la vai:

O que fazer para setar atributos com argumentos mais concretos ou consistentes?
quando por exemplo:

tenho um Bean PessoaFisica que possui um atributo sexo, dentre outros, +/- como segue:

public class PessoaFisica{
  . . .
  private Character sexo;
  . . .
  public void setSexo(Character sexo){
    this.sexo = sexo;
  }
  . . .
}

E assim possuo vários beans com atributos desse tipo, não precisaria ser necessariamente Character,
por que no BD eles são na maioria Char(1) ou SmallInt com restrições/check’s

Como poderia ser passado este argumento de uma forma que ate na compilação, desse erro, me entendem?
(em delphi é possivel declarar e utilizar um Type)

Como poderia ser feito?
Vi alguns exemplos com Enums, será?,
Outros com atributos estáticos (mas estes não impedem a utilização de qualquer outro obj do mesmo tipo) ?.
Ou ainda uma classe para cada tipo de param direferenciado?
Ou apenas uma validação no proprio set?

Vallew pessoal e obrigado desde ja…
abraço!

dooda:

Olá pessoal,

Pode ser uma dúvida simples, mas dei uma procurada aqui no fórum no pai de todos os dúvidosos (google) e não achei nada interessante pra minha duvida, então la vai:

O que fazer para setar atributos com argumentos mais concretos ou consistentes?
quando por exemplo:

tenho um Bean PessoaFisica que possui um atributo sexo, dentre outros, +/- como segue:

public class PessoaFisica{
  . . .
  private Character sexo;
  . . .
  public void setSexo(Character sexo){
    this.sexo = sexo;
  }
  . . .
}

E assim possuo vários beans com atributos desse tipo, não precisaria ser necessariamente Character,
por que no BD eles são na maioria Char(1) ou SmallInt com restrições/check’s

Como poderia ser passado este argumento de uma forma que ate na compilação, desse erro, me entendem?
(em delphi é possivel declarar e utilizar um Type)

Como poderia ser feito?
Vi alguns exemplos com Enums, será?,

sim, por exemplo:

public Enum Genero {
    MASCULINO,
    FEMININO

   boolean isMasculino(){
         return this==MASCULINO;
   }

  boolean   isFeminino(){
return this==FEMININO;
   }
}

public class PessoaFisica{
  . . .
  private Genero genero;
  . . .
  public void setGenero (Genero genero){
    this.genero= genero;
  }
  . . .
}

// uso 

PessoaFisica pessoa = ...
pessoa.setGenero(Genero.MASCULINO);

if (pessoa.getGenero().isMasculino()){
        return "Sr";
} else {
       return "Sra";
}

Bom, então se é assim…

acho que Enums é realmente uma boa saída :oops:

Obrigado!!!

dooda:

Bom, então se é assim…

acho que Enums é realmente uma boa saída :oops:

Obrigado!!!

Você pode ainda…

public enum Genero { MASCULINO(0), FEMININO(1); private Teste1(int codigo) { this.codigo = codigo; } private int codigo; public Genero valueOf(int valor) { if (valor == 1) { return FEMININO; } else { return MASCULINO; } } public int decode() { return this.codigo; } public int decode(Genero g) { return g.codigo; } }

fw

Pois é com a indicaçao dos colegas, implementei com Enums e gostei do resultado e usabilidade… =P

um esboço pra testes ficou como o exemplo do sergiotaborda porém implementei um metodo’zin
pra utilizar pelo meu Dao manual :oops:

mas gostei assim

public enum SexoPessoa {
	MASCULINO,
	FEMININO;
	
	public boolean isMasculino(){
		return this==MASCULINO;
	}
	
	public boolean isFeminino(){
		return this==FEMININO;
	}
	
	public Character getAsChar(){
		Character value = null;
		
		switch (this) {
		case MASCULINO:
			value = 'M';
			break;
		case FEMININO:
			value = 'F';
			break;
		}
		
		return value;
	}
}

e pra EstadoCivil fico bao tamen…

public enum EstadoCivil {
	SOLTEIRO,
	CASADO,
	DIVORCIADO,
	AMASIADO,
	VIUVO;
	
	public boolean isSolteiro(){
		return this==SOLTEIRO;
	}
	
	public boolean isCasado(){
		return this==CASADO;
	}
	
	public boolean isDivorciado(){
		return this==DIVORCIADO;
	}
	
	public boolean isAmasiado(){
		return this==AMASIADO;
	}
	
	public boolean isViuvo(){
		return this==VIUVO;
	}
	
	public Character getAsChar(){
		
		Character value = null;
		
		switch (this) {
		case SOLTEIRO:
			value = 'S';
			break;
		case CASADO:
			value = 'C';
			break;
		case DIVORCIADO:
			value = 'D';
			break;
		case AMASIADO:
			value = 'A';
			break;
		case VIUVO:
			value = 'V';
			break;
		}
		
		return value;
	}

}

dooda:

Pois é com a indicaçao dos colegas, implementei com Enums e gostei do resultado e usabilidade... =P

um esboço pra testes ficou como o exemplo do sergiotaborda porém implementei um metodo'zin
pra utilizar pelo meu Dao manual :oops:

mas gostei assim

public enum SexoPessoa {
	MASCULINO,
	FEMININO;
	
	public boolean isMasculino(){
		return this==MASCULINO;
	}
	
	public boolean isFeminino(){
		return this==FEMININO;
	}
	
	public Character getAsChar(){
		Character value = null;
		
		switch (this) {
		case MASCULINO:
			value = 'M';
			break;
		case FEMININO:
			value = 'F';
			break;
		}
		
		return value;
	}
}

e pra EstadoCivil fico bao tamen...

public enum EstadoCivil {
	SOLTEIRO,
	CASADO,
	DIVORCIADO,
	AMASIADO,
	VIUVO;
	
	public boolean isSolteiro(){
		return this==SOLTEIRO;
	}
	
	public boolean isCasado(){
		return this==CASADO;
	}
	
	public boolean isDivorciado(){
		return this==DIVORCIADO;
	}
	
	public boolean isAmasiado(){
		return this==AMASIADO;
	}
	
	public boolean isViuvo(){
		return this==VIUVO;
	}
	
	public Character getAsChar(){
		
		Character value = null;
		
		switch (this) {
		case SOLTEIRO:
			value = 'S';
			break;
		case CASADO:
			value = 'C';
			break;
		case DIVORCIADO:
			value = 'D';
			break;
		case AMASIADO:
			value = 'A';
			break;
		case VIUVO:
			value = 'V';
			break;
		}
		
		return value;
	}

}

Ih, gostei, ó?! Tava tentando trabalhar com ENUM mas me enrolava um pouco.. =)

Cara, mas uma coisa. Quando tu recupera o estada civil "M" do banco, como tu insere Genero.MASCULINO na Pessoa ??
Faz um IF no DAO mesmo?? :(

[]s

uchoa

eu fiz com um IF no dao mesmo, mas também poderia ser feito com um método
no Bean que recebesse um Character, mas de pouco iria adiantar, por que também
precisaria um if o proprio Bean…

Também gostei dos enum’s

abraço!!!

Se quer converter o enum de e para um char sugiro esta abordagem:

public enum Genero {
	MASCULINO('M'),
	FEMININO('F');
	private char caracter;

        private Genero (char caracter){
              this.caracter = caracter;
        }
	public boolean isMasculino(){
		return this==MASCULINO;
	}
	
	public boolean isFeminino(){
		return this==FEMININO;
	}
	
	public char toChar(){ // poderia usa o toString 
		return caracter;
	}

         public static Genero valueOf(char character){
              if (character == 'M'){
                    return MASCULINO;
              } 
              return FEMININO;
         }
}

Bom, tudo depende do nível de abstração que você quer, mas nesses casos eu prefiro fazer esse tipo de if no próprio DAO (quando se tem um).

Quando você faz o if no DAO, o DAO que precisa saber como isso foi implementado no banco (pensando que em um determinado banco você pode utilizar um char, em outro você pode utilizar int, e por aí vai). Pra mim, a responsabilidade de persistir e recuperar os objetos é do DAO, e por isso ele que deve saber como traduzir de um mecanismo para o outro.

Da forma como você fez no enum, dá a impressão de que o enum - que faz parte do seu domínio - tem que saber como será implementado a persistência.

[]'s

chicobento:

Bom, tudo depende do nível de abstração que você quer, mas nesses casos eu prefiro fazer esse tipo de if no próprio DAO (quando se tem um).

Quando você faz o if no DAO, o DAO que precisa saber como isso foi implementado no banco (pensando que em um determinado banco você pode utilizar um char, em outro você pode utilizar int, e por aí vai). Pra mim, a responsabilidade de persistir e recuperar os objetos é do DAO, e por isso ele que deve saber como traduzir de um mecanismo para o outro.

Da forma como você fez no enum, dá a impressão de que o enum - que faz parte do seu domínio - tem que saber como será implementado a persistência.

[]'s

Hhmm, beleza, faz sentido…

Mas, estendendo um pouco mais a discursão, o DAO é uma maneira de refletir o estado da aplicação na persistencia. Como não existe ENUM Banco, eu salvo um Char e faço o IF no DAO mesmo. Beleza.
Mas quando eu exponho o estado da aplicação a outras interfaces, que também não existe ENUMs ?
Digo, quando eu imprimo o gênero da pessoa num HTML, por exemplo. No mometo de recuperá-lo (como String!) terei que fazer um outro IF no Servlet…
A mesma idéia se eu tiver uma interface Swing que use um checkbox pra dizer se determinada pessoa é do gênero Masculino ou não (ou seja, Boolean). Mais um IF quase idêntico…
Agora imagine se forem vários estados, como o Estado Civil que postaram aqui em cima.

Não seria mais interessante que essas conversões ficassem a cargo do próprio ENUM, não?!

[]s

uchoaaa:

chicobento:

Bom, tudo depende do nível de abstração que você quer, mas nesses casos eu prefiro fazer esse tipo de if no próprio DAO (quando se tem um).

Quando você faz o if no DAO, o DAO que precisa saber como isso foi implementado no banco (pensando que em um determinado banco você pode utilizar um char, em outro você pode utilizar int, e por aí vai). Pra mim, a responsabilidade de persistir e recuperar os objetos é do DAO, e por isso ele que deve saber como traduzir de um mecanismo para o outro.

Da forma como você fez no enum, dá a impressão de que o enum - que faz parte do seu domínio - tem que saber como será implementado a persistência.

[]'s

Hhmm, beleza, faz sentido…

Mas, estendendo um pouco mais a discursão, o DAO é uma maneira de refletir o estado da aplicação na persistencia. Como não existe ENUM Banco, eu salvo um Char e faço o IF no DAO mesmo. Beleza.
Mas quando eu exponho o estado da aplicação a outras interfaces, que também não existe ENUMs ?
Digo, quando eu imprimo o gênero da pessoa num HTML, por exemplo. No mometo de recuperá-lo (como String!) terei que fazer um outro IF no Servlet…
A mesma idéia se eu tiver uma interface Swing que use um checkbox pra dizer se determinada pessoa é do gênero Masculino ou não (ou seja, Boolean). Mais um IF quase idêntico…
Agora imagine se forem vários estados, como o Estado Civil que postaram aqui em cima.

Não seria mais interessante que essas conversões ficassem a cargo do próprio ENUM, não?!

[]s

public String toString() {
    return this == MASCULINO ? "masculino" : "feminino";
}

Tipo, quem se preocupa em mapear a representação do enum na persistência é o DAO. Mas isso não significa que para Stringficar o enum é necessário socar ifs em todos os lugares, a menos que seja algum tipo de representação bem peculiar e única daquele local (que é exatamente o que ocorre no caso do DAO).

uchoaaa:

Hhmm, beleza, faz sentido…

Mas, estendendo um pouco mais a discursão, o DAO é uma maneira de refletir o estado da aplicação na persistencia. Como não existe ENUM Banco, eu salvo um Char e faço o IF no DAO mesmo. Beleza.
Mas quando eu exponho o estado da aplicação a outras interfaces, que também não existe ENUMs ?
Digo, quando eu imprimo o gênero da pessoa num HTML, por exemplo. No mometo de recuperá-lo (como String!) terei que fazer um outro IF no Servlet…
A mesma idéia se eu tiver uma interface Swing que use um checkbox pra dizer se determinada pessoa é do gênero Masculino ou não (ou seja, Boolean). Mais um IF quase idêntico…
Agora imagine se forem vários estados, como o Estado Civil que postaram aqui em cima.

Não seria mais interessante que essas conversões ficassem a cargo do próprio ENUM, não?!

[]s

Sim, na view vc faz um if.
Do tipo, if (genero.isMasculino()) imprima “Masculino”, ou recupere do seu arquivo de internacionalização. Pois imprimir na sua view “M” ou “F” também não faz mto sentido.
É assim que funciona, cada camada com sua responsabilidade: DAO traduz para como ele vai armazenar, View traduz para como ele vai apresentar.
No displaytag por exemplo, vc resolve isso na camada view com um “Decorator”, que é uma interface que vc implementa, que dado uma propriedade do objeto, vc transforma ela em uma representação textual coerente com a sua view.

Mesmo que vc adicionar um código do tipo:

não vai resolver na sua View, pro caso do M necessitar ser apresentado em maiúsculo, entre os vários outros casos. Lembrando que na view, ele pode apresentar em singular, plural dependendo do contexto, portanto seu Enum pode ter N modos de ser apresentado.