Porque utiliza uma interface XXXService para depois implementar co XXXServiceImpl

Leia essa entrevista com ninguém menos que o Erich Gamma (criador do JUnit, Eclipse e co-autor do livro Design Patterns), sobre a importância de se programar para interfaces e não para uma implementação concreta: http://www.artima.com/lejava/articles/designprinciples.html

Ter uma interface, que possua todos os métodos de uma classe Impl… para mim não faz muito sentido…

Causa apenas excesso de trabalho…

Programar para interfaces não é simplismente programar com interface (java)… e sim programar por contrato…

Você pode programar para interfaces (no sentido do contrato) mesmo sem utilizar interface (java)…

Ter uma interface (java) que possui todos os métodos de uma determinada classe, e essa interface não possui outras possíveis implementações, não justifica a sua utilização…

Mesmo porque essa interface e essa classe Impl tem 99% de chance de não ser reaproveitada…

Outra coisa é se pensar numa arquitetura reaproveitável. Nesse caso, é provável que por definição da arquitetura, a interface se fará necessária…

Viny, algumas vezes eu discordo dessa opnião, por exemplo qual a vantagem de se programar para a interface? Você além de menor acoplamento, vc tem mais segurança na alteração de uma classe, porém o que a gente ve por ai, é o uso de interfaces que não servem para nada, qual a vantagem de se ter uma interface no seu sistema? Abstrair a informação, permitir que você possa alterar sua implementação, por exemplo de um DAO, para Hibernate, JDBC, sei la qualquer outra coisa, mas por exemplo, em um framework como o Spring, para a Interface ClienteDAO, devemos ter única e exclusivamente uma implementação para ser injetada pelo container, c vc quiser alterar, ou vc altera XML, annotations e talz, então ai me pergunto qual a vantagem de se utilizar nesse modo? É logico que com a interface você mantem as duas classes simultaneamente, ou seja metodo novo, deve ser implementado para as duas, mas se eu quiser mudar o new para essa classe? Sobrescreever o objeto concreto pelo novo?

Em se falando em manutenção é mais simples, mas eis que surge a dúvida, dificilmente essa abordagem é utilizada em sistemas reais, o que vemos são um apunhado de interfaces com seus impl e nada mais, somente retrabalho, ou trabalho dobrado, em alguns casos acho que andam abusando disso.

Minha Humilde opnião.

Concordo com o Felagund. Acho que ficou melhor argumentado que meu post

Concordo com vocês. Aliás, até mesmo o gamma concorda (alguém chegou a ler a entrevista)?

As interfaces são importantes nas fronteiras entre sistemas, ou em locais onde seja interessante encapsular algum tipo de tecnica ou tecnologia. Agora, usar interfaces só para cumprir tabela vai deixar o sistema confuso desnecessariamente.

As interfaces te dão a possibilidade de mocks, ou de criar decorators. No exemplo do Felagund, poderíamos ter um MockClienteDao, usando para isso uma interface, que carregasse os dados de um dispositivo mais rápido que o BD, como mapas em memória, o que poderia reduzir o tempo de testes.

Via de regra eu não saio criando interfaces, mas assim que a necessidade de ter mais de uma implementação surge, eu não hesito em criar a interface, e separar as implementações concretas, nem que isso seja um refactoring um pouco mais custoso para meu sistema.

Vejo que essa discursão é antiga!

Só para concluir. Se eu não necessitar de mais que uma implementação de algo preciso utilizar essa estrutura só por utilizar pois não irei ter vantagem nisso!? Meu sistema é de médio porte. Minha única preocupação é desenvolver nos moldes dos sistemas desenvolvidos no mercado. Para mim a estrutura citada no primeiro post é suficiente??

Grato!

ViniGodoy:

Via de regra eu não saio criando interfaces, mas assim que a necessidade de ter mais de uma implementação surge, eu não hesito em criar a interface, e separar as implementações concretas, nem que isso seja um refactoring um pouco mais custoso para meu sistema.

Ai sim concordo plenamente, classe de comportamentes e/ou necessisdades iguais podem ser abstraidas em uma interface

Como assim comportamentos e necessidades igual?

Por exemplo, imagine que vc tem uma classe que receba um determinado Objeto, Cliente, e exista uma regra que para determinados clientes, o saldo da sua conta deve ser multiplicado por 1.5%.

Ai seu querido cliente :), resolve que para os novos clientes o saldo da conta deve ser 1%, veja bem, para os novos os antigos vão continuar com essa informação. Imaginemos que esse percentual seja sempre a mais, como se fossem juros de um banco

Vc cria uma interface por exemplo:

public interface ManutencaoConta{
   BigDecimal calculaJuros(Cliente cliente);
}

Assim vale a pena, o exemplo foi ridiculo, mas é só para ilustrar a situação. no caso vc converteria sua classe Concreta CalculoJurosConta para impementar a interface ManutencaoConta, e criaria uma nova classe pra fazer o mesmo.

É logico que vc resolveria isso adicionando o prametro dos juros, mas isso não vem ao caso agora

Já complicaria ter só um parâmetro se para os novos a formula fosse a do juro composto com 1%, e para os antigos a do juro simples com 1.5%. Como o que mudaria daí não é só o percentual, mas a fórmula do calculo, fica melhor ter a interface e determinar o processo em si de calculo por polimorfismo, do que começar a fazer switchs dentro da sua classe.

O uso da interface dessa forma é uma implementação do padrão Strategy.