Os Objetos Modelo Devem Ter Interfaces?
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?
6 answers
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.
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.
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.
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 é:
- 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])
- você precisa expor o seu modelo de domínio a clientes externos e quer esconder detalhes de implementação deles
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.