Discussão Saudável - Interface Como Atributo de Objeto

Utilizei uma abordagem parecida uma vez no tratamento de arquivo enviados pelo cliente, onde diferentes tipos de arquivo implementavam uma certa interface e tinham um tipo de tratamento diferenciado.

Para o caso especifico de Perfil tenho utilizado enums, já que em geral o perfil apenas restringe o acesso a certas areas do sistema, nesse caso os enums tem suprido minha necessidade.

Falando do uso de interfaces gosto de utiliza-las principalmente quando essas evitam um aglomerado de ifs e dão lugar a classes polimórficas, o código fica mais organizado e mais elegante (dá gosto de ver), a manutenção também fica mais simples, podendo adicionar novas opções sem que seja necessário muitas alterações no código.

Mas como você planeja usar esse atributo?

Tive a mesma dúvida.

Outra pergunta, quais são os métodos dessa interface?

(Se estiver usando hibernate, terá que fazer alguns malabarismos para fazer funcionar. Quando o mapeamento era feito via xml, tinham umas formas mais elegantes de fazer. Com anotações, a um tempo atrás, nem sei se era possível, tem que ver como está hoje.)

Calel, sim ja utilizei essa abordagem anteriormente assim como vocÊ nesse formato, o que

entrou na discussão de dev. para implementação , foi o uso de interfaces como atributo,

de uma forma similar a essa:

Interface Geral {

//…

}

Class N1 implements Geral{
//…

}

Class N2 implements Geral {

//…

}

Class Usuario{

private Geral tipoDeUsuario;

//…
}

A classe usuario iria possuir um atributo que iria possuir o item n1 OU N2

que iria diferenciar o tipo de usuario verificando o tipo de instancia do objeto tipo

de usuario que o mesmo possuia.

Rogel, utilizo NoSQL , em uma formatação que estamos fazendo nosso relacionamento

manualmente.

abcs

Se for só para diferenciar os tipos, acho que enum é uma solução mais elegante.

sim sim seria pra isso,

Mas o que voces pensam sobre o uso de interfaces dessa maneira

eh uma discussao saudavel, usar ou não usar…

abcs

Não vejo problemas não. Mas precisaria de um exemplo que realmente necessita-se essa abordagem.
No exemplo mencionado, ao meu ver, não precisa. Então, usar sem necessidade eu creio não ser interessante.

Desenvolvo há 8 anos, até hoje não houve uma situação que me obrigasse a ter uma abordagem assim. Uma abordagem em que o mapeamento mais puro OO precisasse de uma interface como atributo de uma entidade. Alguém teria um exemplo?

rogelgarcia:

Não vejo problemas não. Mas precisaria de um exemplo que realmente necessita-se essa abordagem.
No exemplo mencionado, ao meu ver, não precisa. Então, usar sem necessidade eu creio não ser interessante.

Desenvolvo há 8 anos, até hoje não houve uma situação que me obrigasse a ter uma abordagem assim. Uma abordagem em que o mapeamento mais puro OO precisasse de uma interface como atributo de uma entidade. Alguém teria um exemplo?

Pra fazer:

interface MyInterface{/*...*/} 

class A implements MyInterface{/*...*/} 

class B implements MyInterface{/*...*/}

e depois:

class Foo{
  MyInterface instance;

  void do(){
     if( instance instanceof A){
        //...
     else if( instance instanceof B){
        //...
     }
  }
}

é melhor usar uma classe só com um campo para diferenciar o tipo, e aí para esse campo você usa uma enumeração. Usar interface nesse caso seria um erro por dois motivos:

1 - você não está usando polimorifismo, pois você tem que fazer um teste de tipo

2 - o resultado no BD seria o mesmo. Uma das abordagens para mapear hierarquia de tipos é colocar os campos de todas as classes em uma única tabela e mais um campo para diferenciar o tipo, ou seja, é muito próximo do que seria criar uma única classe e usar um campo para diferenciar o tipo, com a diferença que o mapeamento fica mais claro