Separar interface de implementação

Na verdade a idéia disso é diminuir o acoplamento de seu sistema.

a idéia seria mais ou menos esta…

class CadastroGUI extends JFrame {  
       
     private final CadastroEngine ENGINE = new CadastroEngineDBImpl();  
     private JTextField textField = new JTextField();  
     private JButton btn = new JButton("Cadastra");  
       
     public CadastroGUI() {  
           
         add(textField);  
         add(btn);  
         //define-se o layout e tal ..  
           
         btn.addKeyListener(new KeyAdapter() {  
             @Override  
             public void keyPressed(KeyEvent e) {  
                 ENGINE.cadastra(textField.getText());  
             }  
         });  
           
     }  
       
 }  

public interface CadastroEngine {
  public void cadastra(String nome);
  public void exclui(String nome);
}

public class CadastroEngineDBImpl implements CadastroEngine {
  public void cadastra(String nome) {
    /*codigo*/
  }
  public void exclui(String nome) {
    /*codigo*/
  }
}

Isso por que…
Hoje, seu cadastro é feito dessa maneira, tipo em um banco de dados x…
mas amanhã, seu cadastro pode vir a ser em um arquivo .txt organizado…
e dai como fica???

basta implementar a interface com as novas regras.

public class CadastroEngineArquivoImpl implements CadastroEngine {
  public void cadastra(String nome) {
    /*codigo*/
  }
  public void exclui(String nome) {
    /*codigo*/
  }
}

E na sua chamada mudar a instancia da classe…
O mais certo talvez seria fazer injeção de dependencia…
pois para a sua classe do frame nao precisa conhecer quem faz a implementação correta, precisa apenas que alguem garanta as assinaturas de métodos para ela…

valeu…

Só acrescentado que nbluis disse , programe para Interface e não para implementações.

Beleza!

Acho que to pegando melhor esse negócio de programar pra interfaces, um pouco complicado é saber qnd fazer a interface, pois não são Todas as classes que vão precisar de interface… ex: a classe CadastroGUI não necessita de uma interface ICadastroGUI.
Com o tempo eu vou enxergando melhor.

Aproveitando, para dar um get no nome qual é melhor ou mais usado:
colocar o getNome() no CadastroGUI:

CadastroGUI.getNome(){

return ENGINE.getNome();

}

OU

CadastroGUI.getEngine()
//daí o usuário faz gui.getEngine().getNome();

?

eu particularmente estou usando o getEngine(), pois acho q fica menos “poluído” e menos acoplado.

Bom, espero que tenha entendido que programar para interfaces não é fazer telas e sim criar
interfaces (por oposição a classes), que depois alguma classe irá implementar.

Por outro lado, separar a lógica “que faz alguma coisa” da tela que recebe os comandos do usuário é uma parte do padrão MVC (Model-View-Controller) em particular a parte View-Controller.

Blz, vou ler sobre MVC então…

Obrigado!

Na verdade, utilizar injeção de dependências, é o MAIS CORRETO para separar interfaces de implementações.

Na verdade, utilizar injeção de dependências, é o MAIS CORRETO para separar interfaces de implementações.

No caso, injeção de dependência é o mesmo que MVC?
Esse negócio de MVC é um pouco complicado hein…rs Em particular pra entender o Observer, como que integra tudo… estou vendo este exemplo pra tentar entender legal:
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm

No caso, injeção de dependência é o mesmo que MVC?
Esse negócio de MVC é um pouco complicado hein…rs Em particular pra entender o Observer, como que integra tudo… estou vendo este exemplo pra tentar entender legal:
http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/arqu/mvc/mvc.htm

PS. Esse software do GUJ tá de sacanagem hein… agente clica em enviar, ele finge que não enviou, agente clica denovo, e ele envia duas vezes…
Isso qnd não abre a caixa de diálogo pra download do arquivo .java.
:\

pode crer wellington… MAS IoC e DI não tem muito a ver com MVC não… De uma olhada na página do fowler, que tem explicações interessantes…

IMHO, não se deve pensar assim.
qual a real possibilidade de isso acontecer?? quantas vezes implementamos soluções mirabolantes pensando no “Se um dia…” e isso nunca acontece?
programe de maneira mais facil e simples possivel, não fique pensando no “Se…”, isso é uma mania que nos desenvolvedores temos. a maioria dos sistemas tem funcionalidades que nunca são usadas e so adicinaram cimplexidade na cosntrução.
outra coisa, se essa mudança citada realmente acontecesse(trocar o BD por arquivo), implementar isso seria o menor dos problemas em relação ao resto do sistema.

sobre programar para a interface não para a implementação, não entenda interface como tela ou sempre criar interfaces java. a ideia não é bem essa. interface nesse caso é o que o mundo externo vai conhecer do seu objeto e a maneira como vai interagir com ele. a ideia é mudar o comportamento sem impactar em quem conhece a interface.

[]'s

jgbt:

nbluis:

…

IMHO, não se deve pensar assim.
qual a real possibilidade de isso acontecer?? quantas vezes implementamos soluções mirabolantes pensando no “Se um dia…” e isso nunca acontece?
programe de maneira mais facil e simples possivel, não fique pensando no “Se…”, isso é uma mania que nos desenvolvedores temos. a maioria dos sistemas tem funcionalidades que nunca são usadas e so adicinaram cimplexidade na cosntrução.
outra coisa, se essa mudança citada realmente acontecesse(trocar o BD por arquivo), implementar isso seria o menor dos problemas em relação ao resto do sistema.

sobre programar para a interface não para a implementação, não entenda interface como tela ou sempre criar interfaces java. a ideia não é bem essa. interface nesse caso é o que o mundo externo vai conhecer do seu objeto e a maneira como vai interagir com ele. a ideia é mudar o comportamento sem impactar em quem conhece a interface.

[]'s

Está certo… na verdade o exemplo foi o que me veio em mente no momento para demonstrar a abstração da implementação.

Eu utilizo interfaces para separar melhor meu codigo … que pode ser chamado de programação por camadas…
Ex.:
Tenho a classe InsereFucionario(que insere os dados em banco de dados) que implementa a IRepositorioFuncionario que tem os metodos de inserir remover e etc.
E tenho outra Classe chamada ControlaFuncionario(ela é responsavel em enviar os dados informados pelo usuário) que tem como atributo principal IRepositorioFuncionaio iFuncionario = new InsereFuncionario().
E podendo reutilizar o codigo criando uma classe InsereFuncionario2 que implementa o mesma interface IRepositorioFuncionario, podendo ser utilizada por exemplo para inserir os dados em arrays.
Espero ter ajudado. Se o amigo wellington7 tiver alguma duvida ou interessado neste tipo de implementação posso passar um exemplo pra vc por e-mail.

t+ :lol: