Melhor maneira de estruturar a GUI

JavaGuru Membro desde: 16/03/2007 14:03:02 Mensagens: 287 Offline

Olá pessoal,
bem, estou construindo uma aplicação relativamente simples para desktop, sem nada de Web ou BD.
Minha duvida é sobre a estrutura que fiz a interface grafica onde tenho JPanel com uma JToolBar uma JTree e um JScrollPane.
Dentro do JScroolPane tenho algumas JTables.
O caso é que a JToolBar tem botoes para adicionar componentes nas celulas da JTable que estiver com o foco, fiz algo assim:

[botao da JToolBar pressionado] >> [JToolBar chama o metodo addComponent() do JPanel] >> [JPanel chama o metodo addComponent() do ScroolPane] >> [ScroolPane chama o metodo addComponent da JTable atual, a que estiver focada, se nenhuma estiver nao faz nada]

A idéia com todas essas delegações é diminuir acoplamento e facilitar os teste unitarios (e realmente facilitou), mas gostaria de opinioes dos mais experientes, nao sei se essa arquitetura pode causar problemas no futuro (o sistema ainda vai crescer muito).

PS. Todas as classes sao implementacoes de interface. DefaultIDETable é implementacao da interface IDETable, isso facilita para fazer os testes com JUnit, pois posso criar outras implementacoes da tabela. Nao sei se vem ao caso.

--- update

Deixa eu mostrar um pouco de codigo pra facilitar...

// Dentro de cada pacote tem varias classes e interfaces, vou colocar apenas as relativas a pergunta para nao poluir

---

package app.project;

public interface Project {

public void addComponent(); // chamado pela toolBar, ou pelo atalho de teclado

// outros metodos

}

class DefaultProject extends JPanel implements Project {

private final MyTooBar toolBar = new MyToolBar(this);
  private TablePane tablePane;

public void addComponent() {
    tablePane.addComponent();
  }

// varios outros metodos e atributos

}

// outras classes e interfaces deste pacote

---

package app.project.tablesPane

public interface TablePane {

addComponent();

// outros metodos

}

class DefaultTablePane extends JScrollPane implements TablePane {

private Project parentProject;

private Vector<MyTable> myTables;

// inside button's actionPerformed...
   parentProject.addComponent();

// outros metodos e atributos

}

// outras classes e interfaces deste pacote

---

package app.project.tablesPane.table;

public interface MyTable {

addComponent();

// outros metodos

}

class DefaultMyTable extends JTable implements MyTable {

// adiciona o componente

}

// outras classes e interfaces deste pacote

---

Virtual Machine Man Membro desde: 17/09/2008 12:58:32 Mensagens: 669 Offline

Olhá, achei meio estranho as várias classes terem que "repassar" a mensagem. Para Guis, para esses casos em que elas devem responder a comandos, o padrão Observer é o mais indicado. Basicamente vc cria um Evento que contém as informações que suas UI necessitam, e deixa que cada uma implemente sua própria forma de se atualizar. Assim vc pode implementar várias UI's que encapsulam a responsabilidade de se atualizar.

JavaGuru Membro desde: 16/03/2007 14:03:02 Mensagens: 287 Offline

Entendo. O padrão observer é criar os listeners, certo? Eu estava fazendo com listeners antes, mas como cada classe tinha apenas 1 objeto como listener eu achei que seria mais interessante passar a classe como "parent" - pai - (alguns vão preferir dizer "owner" - dono) da classe que vem abaixo.. Por exemplo, o Project (JFrame) é o pai do Panel.
Ainda assim, acha que seria melhor usar o Observer?
E, caso sim, concorda que ficaria muito acoplado, já que a JTable precisaria ouvir os eventos da JToolBar que esta 3 níveis acima na hierarquia? JToolBar está em JFrame que contém JPanel que contém (entre outros componentes) JScrollPane e que contem (entre outros componentes) a JTable.

JavaGuru Membro desde: 16/03/2007 14:03:02 Mensagens: 287 Offline

Na verdade... (me veio essa luz agora) Se eu usar essa arquitetura com "parents", eu estou aumentando o acoplamento, e dificultando meus testes unitarios.. Se eu tiver um sistema com listeners, mesmo que cada objeto vá ter apenas 1 listener, eu diminuiria o acoplamento e me livraria de algumas classes extras que precisei criar para os testes..
Entretanto, para o evento da toolBar, a melhor arquitetura (menos acoplada) ainda seria passar um comando addComponent() para o JFrame, e dele descendo para o JPanel, depois o tablesScrollBar e para o JTable que estiver em foco. Concordam?

Notícias, artigos e o maior fórum brasileiro sobre Java