Qual a vantagem de se programar orientado a Interfaces?

Programação Java
#1

Pessoal, vejo o pessoal falando que deve-se trabalhar com interfaces, com estruturas assim:

InterfaceModel obj = new ImplInterfaceModel();

Dizem que é, que se algo for alterado, o código não é modificado! Mas alguem poderia me dar um exemplo?

Obrigado! :XD:

#2

Independência e desacoplamento da implementação.

RelatorioAnalitico relatorio = new RelatorioXML();
RelatorioAnalitico relatorio = new RelatorioPDF();
RelatorioAnalitico relatorio = new RelatorioHTML();

E se quiser abstrair ainda mais, usa DI(Dependence of Injection) para criação das instâncias.

#3

Aqui no próprio GUJ tem um artigo falando sobre Interface muito bom http://www.guj.com.br/java.tutorial.artigo.123.1.guj

Interface é algo que todo programador deveria usar e abusar, principalmente para evitar acoplamento desnecessário e assim melhorando o reuso do código, além de deixar os testes unitários mais fáceis de ser implementados.

Acho que você começa a enchergar o uso da Interface a partir do momento que você começa a de fato fazer testes unitários e ver um monte de acoplamento que deveria ser evitado (pelo menos comigo foi assim).

Espero ter ajudado

#4

O bom de usar interfaces é que não fica preso a instância mas eu não consigo ver vantagem num código assim…

IPessoaDao pessoaDao = new PessoaHibernateDaoImpl(); pessoaDao.create(); pessoaDao = new PessoaTopLinkDaoImpl(); pessoaDao.save(); pessoaDao = new PessoaJdoDaoImpl(); pessoaDao.remove(); Agora se tivesse um framework para controlar a injeção de dependência como o Spring aí na minha opinião tem vantagem e muitaaaa… ApplicationContext ap = new ClassPathXmlApplicationContext(""); IPessoaDao pessoaDao = (IPessoaDao) ap.getBean("pessoaMysql"); pessoaDao.create(); pessoaDao = (IPessoaDao) ap.getBean("pessoaTopLink"); pessoaDao.save(); pessoaDao = (IPessoaDao) ap.getBean("pessoaJdo"); pessoaDao.remove(); Aí sim fica bem flexível e se tivesse um factory que cuidasse dos nomes dos beans ficaria melhor ainda.

#5

[quote=Rafael Nunes]Independência e desacoplamento da implementação.

RelatorioAnalitico relatorio = new RelatorioXML();
RelatorioAnalitico relatorio = new RelatorioPDF();
RelatorioAnalitico relatorio = new RelatorioHTML();

E se quiser abstrair ainda mais, usa DI(Dependence of Injection) para criação das instâncias.[/quote]

tá. Mas, nesses casos ele nao conseguirá executar metodos existentes nas classes de implementação (meotodos q nao foram assinados dentro da interface). Isso é bom lembrar =)

#6

[quote=pardal_nb]
tá. Mas, nesses casos ele nao conseguirá executar metodos existentes nas classes de implementação (meotodos q nao foram assinados dentro da interface). Isso é bom lembrar =)[/quote]
e qual o problema?
vc tem que entender que o conceito de programar orientado a interface não esta obrigatoriamente ligado ao uso de arquivos interface(como no java).
esse conceito é OO, ele quer dizer que vc deve programar pensando em como seu objeto vai se relacionar com os outros, o que vai estar exposto a outros objetos. Poderia ser uma classe, mas o importante é que outros objetos so conhecam essa classe, e que vc possa mudar o comportamento dessa classe sem que os objetos que se relacionam com ela sintam a mudança.

[]´s

1 curtida
#7

[quote=jgbt][quote=pardal_nb]
tá. Mas, nesses casos ele nao conseguirá executar metodos existentes nas classes de implementação (meotodos q nao foram assinados dentro da interface). Isso é bom lembrar =)[/quote]
e qual o problema?
vc tem que entender que o conceito de programar orientado a interface não esta obrigatoriamente ligado ao uso de arquivos interface(como no java).
esse conceito é OO, ele quer dizer que vc deve programar pensando em como seu objeto vai se relacionar com os outros, o que vai estar exposto a outros objetos. Poderia ser uma classe, mas o importante é que outros objetos so conhecam essa classe, e que vc possa mudar o comportamento dessa classe sem que os objetos que se relacionam com ela sintam a mudança.

[]´s[/quote]

problema nenhum…

lendo o q vc comentou, realmente, isso(o q falei) se for pensando em java =)

#8

Que tal ver o que diz o Erich Gamme, criador do Eclipse, JUnit e co-autor do famoso livro “Padrões de Projeto”?

Design Principles from Design Patterns - A Conversation with Erich Gamma, Part III
In this interview, Erich Gamma, co-author of the landmark book, Design Patterns, talks with Bill Venners about two design principles: program to an interface, not an implementation, and favor object composition over class inheritance.

#9