Os Objetos Modelo Devem Ter Interfaces?

Estou a criar o modelo de domínio no meu sistema. Ao projetar meus objetos modelo, devo fazer interfaces para cada objeto entidade? As pessoas me disseram que nosso nível web não deve se importar com a implementação de uma entidade e nós devemos ser capazes de trocar implementações, mas eu não tenho certeza de que isso alguma vez aconteceria.

Por exemplo, se temos uma aula de professores que mantém uma lista de alunos, o método getStudents pode ser:

public List<Student> getStudents() {
      return this.students;
}

ou isto:

public List<Student> getStudents() { 
     return someExternalService.retrieveStudents();
}
Entendo este benefício, mas qual é a prática geral?

Author: skaffman, 2010-03-10

6 answers

A menos que tenhas boas razões para pensar que precisas de trocar o modelo, eu não me preocuparia com isso ainda. Baseado no princípio YAGNI ([[2]} não vais precisar dele)
 7
Author: David, 2010-03-09 23:11:14
Nenhum dos projectos que já vi ou participei tinha interfaces para Entidades de domínio. Mas num dos meus projectos eu tinha interface.NamedEntity:
public interface NamedEntity {
   int getId ();
   String getName ();
}

Todas as entidades do domínio implementaram esta interface. Ele me deu a possibilidade de não criar diferentes conversores jsf para diferentes entidades, mas criar um conversor que usou esta interface em vez de classes de domínio Concreto.

 2
Author: Roman, 2010-03-09 22:46:24
Não posso falar com a prática geral, mas não se trata apenas de esconder a implementação. Trata-se de formalizar a interface como base para documentação e contratos.

Ao abstrair os seus modelos em interfaces, está a criar documentação para os programadores dos clientes de serviços. Dependendo do seu estilo de desenvolvimento, você pode ou não ter já uma descrição formal do seu serviço (por exemplo, uma descrição baseada em WSDL). As Interfaces podem preencher essa necessidade.

 1
Author: Noel Ang, 2010-03-09 23:15:33

Acho que há uma diferença importante entre ter interface para o serviço para recuperar o objecto e o próprio objecto modelo.

Em tempo de execução, o serviço para carregar um objecto modelo pode diferir com base no local onde está a pedir os dados. Mas o formato e tipo de objeto de dados esperado não muda, não importa como você cria este objeto. Portanto, os objetos modelo que carregam o estado não precisariam de uma interface, mas classes de Serviço para criar e carregar esses objetos modelo precisa da interface.

A única razão para os objectos modelo terem interfaces faria sentido se o objecto modelo não fosse apenas um simples tipo de objecto bean, mas um objecto que também expõe algum tipo de comportamento.

 1
Author: Fazal, 2010-03-10 00:18:39

A minha visão geral é que eu não criaria um conjunto de interfaces um-para-um para os modelos de domínio, uma vez que isto não faz mais do que duplicar a estrutura de classes do seu modelo de domínio. Não acrescenta nada de útil.

Os dois casos em que me ocorre imediatamente, EM QUE EUconsideraria introduzir interfaces é:

  1. uma interface descreve o contrato / comportamento de algumas classes no modelo de domínio, onde é útil modelar esse comportamento independente das classes que a executam ([11])
  2. você precisa expor o seu modelo de domínio a clientes externos e quer esconder detalhes de implementação deles
Por outras palavras, adicione interfaces se o ajudarem a descrever o comportamento ou a esconder os detalhes da implementação dos clientes. Outras razões podem ser válidas, mas são duas que me vêm à cabeça.
 0
Author: KarstenF, 2010-03-09 23:55:39

Extrair uma interface é um dos mais simples refactores;na pior das hipóteses é um método de mudança de classe. O esforço para mudar de ideias, uma vez que você tenha encontrado uma razão para fazê-lo, é mínimo. Sempre achei que se uma decisão é fácil de mudar, reforça YAGNI e beija ainda mais. O contra-argumento é que não é muito esforço para criar uma interface inicialmente, o que é verdade, mas a manutenção se soma ao longo do tempo se a decisão é tomada muitas vezes - muitas vezes não a ser usado.

 0
Author: walnutmon, 2011-07-09 02:17:49