Arquivo Discussoes de Programacao e Tecnologia 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:
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.
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
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.
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.
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 =)
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 =)
[]´s
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 =)
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
problema nenhum…
lendo o q vc comentou, realmente, isso(o q falei) se for pensando em java =)
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.