Tá uma mania besta aqui na empresa de dizer que tudo deve ter uma interface. A justificativa é que “isso é uma boa prática”… Não sei, mas isso está me cheirando a papagaio de pirata (sabe? que ouve uma vez e fica repetindo até o infinito?).
Bom, eu queria ver com vocês se estou viajando na maionese ou se o povo é que está “viciado”.
A gente tem um sistema aqui com arquitetura “bolovo” padrão…
Nas BO’s a estrutura é a seguinte:
VO: NotaFiscal (pojo atributos gets e sets)
Interface da BO: NotaFiscalBO (aqui só tem todos os métodos da bo… todas as declarações na verdade…)
Implementação da BO: NotaFiscalBOImpl (essa classe implementa apenas NotaFiscalBO e mais nada)
Isso faz sentido? Tudo bem que se vê em todo lugar que é legal programar para uma interface e não para uma implementação, mas isso não é meio que “demais”??? As interfaces são contratos, mas faz sentido mesmo quando for “assinado” por um cara só? Ou apenas para garantir a implementação dos métodos?
Você tem diferentes implementações de notas fiscais? Senão não faz sentido mesmo!
A meu ver o papagaio de pirata impera na sua empresa, vejo isso até pelo uso VOs e BOs, que é um péssimo método de desenvolvimento, mas isso é outra discussão.
A meu ver é um trabalho desnecessário, que, caso seja necessário um dia, pode ser resolvido facilmente através de uma refatoração. Isso é programar para o amanhã, e não para o hoje.
Para o exemplo citado, sim e uma boa prática alguns dos beneficios serão:
Diversas implementações de sua interface.
Componentização, futuramente você pode querer que seu BO seja um EJB então basta vc disponibilizar a interface para o usuário omitindo assim detalhes da implementação.
Reutilização vc pode criar um objeto que será utilizado em diversos locais, porque não em outros sistemas tbm.
Para o exemplo citado, sim e uma boa prática alguns dos beneficios serão:
Diversas implementações de sua interface.
Componentização, futuramente você pode querer que seu BO seja um EJB então basta vc disponibilizar a interface para o usuário omitindo assim detalhes da regra.
Reutilização vc pode criar um objeto que será utilizado em diversos locais, porque não em outros sistemas tbm.
Facilidade de manutenção.[/quote]
Tá, mas no futuro ele realmente necessitára implementar diversos variações dessas interfaces, componentizar e reutilizar? Se sim ele não pode fazer isso através de uma refatoração para uma interface? Isso não um trabalho desnecessário?
Sua colocação não é inválida, mas estou pensando em desenvolvimento agil, então acho melhor refatorar no futuro, caso seja necessário, de forma a obter os seus itens, do que fazer isso agora.
A questão de manutenção é interessante! Caso seja necessário no futuro fazer os itens 1 a 3 realmente vai ser mais fácil, agora se for necessário apenas adicionar um método a classe para uma nova funcionalidade haverá mais trabalho, neste caso o sistema se tornou mais complexo sem necessidade.
Programar para interfaces não é só cumprir contratos. Esse conceito chama a atenção também para outras coisas como o uso inadequado de herança, por exemplo.
Embora no dia a dia eu não sinta nenhuma necessidade de criar interfaces para certas coisas, acho q isso depende muito da arquitetura e do sistema em si.
Tá mas então qual a finalidade de usar interfaces, ja q sua função é justamente abstrair a implementação?[/quote]
Sim, este é o ponto. Acho que o jargão “implementar para uma interface” está tão incrustado nas cabeças dos desenvolvedores daqui que o uso de interfaces se tornou abusivo (não achei outro adjetivo melhor para qualificar o que temos aqui).
Para cada BO, há uma interface. E não há utilização de uma mesma interface por várias implementações… As justificativas que recebi foram que isso se trata de uma “boa prática” e que como uma BO poderia chamar métodos da outra, as interfaces garantiriam a implementação dos métodos… Mas isso não faz sentido pra mim. Inclusive os nomes que são bizarros: “NotaFiscalBOImpl”. Parece até aquelas homenagens sabe? “Maicoujequison da Silva”…
Como você disse em seu outro post o sistema ganhou uma complexidade desnecessária, e o uso das interfaces me parece indevido.
Se vc tem só uma implementação QUEIMA ESSAS INTERFACES
É tão dificil extrair um interface depois, SE um dia precisar? Fica tentando prever o futuro so vai encher de lixo o sistema. E criar trocentas interfaces inuteis não é uma boa pratica aos meus humildes olhos
Tá mas então qual a finalidade de usar interfaces, ja q sua função é justamente abstrair a implementação?[/quote]
Sim, este é o ponto. Acho que o jargão “implementar para uma interface” está tão incrustado nas cabeças dos desenvolvedores daqui que o uso de interfaces se tornou abusivo (não achei outro adjetivo melhor para qualificar o que temos aqui).
Para cada BO, há uma interface. E não há utilização de uma mesma interface por várias implementações… As justificativas que recebi foram que isso se trata de uma “boa prática” e que como uma BO poderia chamar métodos da outra, as interfaces garantiriam a implementação dos métodos… Mas isso não faz sentido pra mim. Inclusive os nomes que são bizarros: “NotaFiscalBOImpl”. Parece até aquelas homenagens sabe? “Maicoujequison da Silva”…
Como você disse em seu outro post o sistema ganhou uma complexidade desnecessária, e o uso das interfaces me parece indevido.[/quote]
A meu ver seus colegas pegaram um execelente forma de desenvolver e deturparam tudo… começa que para “implementar para uma interface” não é nem necessário usar uma interface, pode ser usada uma classe abstrada e como disse o[quote=el_loko]Programar para interfaces não é só cumprir contratos. Esse conceito chama a atenção também para outras coisas como o uso inadequado de herança, por exemplo.
Embora no dia a dia eu não sinta nenhuma necessidade de criar interfaces para certas coisas, acho q isso depende muito da arquitetura e do sistema em si.[/quote]
[quote=Felagund]Se vc tem só uma implementação QUEIMA ESSAS INTERFACES
É tão dificil extrair um interface depois, SE um dia precisar? Fica tentando prever o futuro so vai encher de lixo o sistema. E criar trocentas interfaces inuteis não é uma boa pratica aos meus humildes olhos[/quote]++
Até pq você não tem ABSOLUTA certeza se vai precisar ou não. YAGNI
[quote=Felagund]Se vc tem só uma implementação QUEIMA ESSAS INTERFACES
É tão dificil extrair um interface depois, SE um dia precisar? Fica tentando prever o futuro so vai encher de lixo o sistema. E criar trocentas interfaces inuteis não é uma boa pratica aos meus humildes olhos[/quote]
Aproveita e manda seus colegas lerem o livro: Design Patterns: Elements of Reusable Object-Oriented Software
Assim vão apreender “o que programar para uma interface”
[quote=drigo.angelo][quote=Felagund]Se vc tem só uma implementação QUEIMA ESSAS INTERFACES
É tão dificil extrair um interface depois, SE um dia precisar? Fica tentando prever o futuro so vai encher de lixo o sistema. E criar trocentas interfaces inuteis não é uma boa pratica aos meus humildes olhos[/quote]++
Até pq você não tem ABSOLUTA certeza se vai precisar ou não. YAGNI[/quote]
++
Defendendo um pouco essa prática, vejo as seguintes vantagens em se utilizar interfaces nesse caso:
Ao criar primeiro as interfaces, o desenvolvedor se vê obrigado a pensar melhor no design dos serviços (no caso os serviços são os BOs).
Isso ajuda a evitar algumas gambiarras que surgem ao longo do tempo, fazendo com que o Client fique dependentes de comportamentos não-documentados dos métodos do serviço.
Fica mais fácil criar testes unitários para as classes do sistema, mockando as dependências.
Recomendo fortemente a adoção de testes automatizados!
Tá uma mania besta aqui na empresa de dizer que tudo deve ter uma interface. A justificativa é que “isso é uma boa prática”… Não sei, mas isso está me cheirando a papagaio de pirata (sabe? que ouve uma vez e fica repetindo até o infinito?).
Bom, eu queria ver com vocês se estou viajando na maionese ou se o povo é que está “viciado”.
A gente tem um sistema aqui com arquitetura “bolovo” padrão…
Nas BO’s a estrutura é a seguinte:
VO: NotaFiscal (pojo atributos gets e sets)
Interface da BO: NotaFiscalBO (aqui só tem todos os métodos da bo… todas as declarações na verdade…)
Implementação da BO: NotaFiscalBOImpl (essa classe implementa apenas NotaFiscalBO e mais nada)
Isso faz sentido? Tudo bem que se vê em todo lugar que é legal programar para uma interface e não para uma implementação, mas isso não é meio que “demais”??? As interfaces são contratos, mas faz sentido mesmo quando for “assinado” por um cara só? Ou apenas para garantir a implementação dos métodos?
[/quote]
Provavelmente seus colegas devem estar usando o padrão onDemand criado por um outro membro do guj!
Programar voltado a interface é realmente uma boa pratica, mas isso nao quer dizer especificamente que toda classe precise estar interfaceada (mas muitas vezes quando voce acha que nao precisa, pode ser que esteja perdendo uma boa oportunidade). O livro do Design Pattenrs prega bastante isso.
Mas se seu sistema esta todo quebrado em BOs, VOs, etc, ha ai um grande problema que deve ser tratado com prioridade.
Como ja citaram, voce pode ler sobre dominio anemico no post do Phillip.