Normas para o uso de classes internas para GUI?

Question

Eu estou querendo saber sobre a prática padrão com classes internas (em Java, mas suponho que se aplica a todas as linguagens OO). Portanto, I tem um ControllerWindow Jframe subclasse que contém um Jpanel subclasse MapPanel que Chamo para (por isso precisa substituir método paintComponent) e que tem de aplicar um ouvinte rato. Minha solução atual que funciona é ter MapPanel em uma classe separada implementação MouseListener mas quando eu mostrei isso para o cara que dirige o meu curso no outro dia ele parecia pensar que (nós temos um pouco de uma língua barreira), este deve ser em um interior classe em ControllerWindow ou pelo menos o MouseListener deve ser uma classe interna.

Então, minha pergunta é qual seria a solução padrão aqui, para colocar um MouseListener na classe interna, os JPanel em uma classe interna diferente ou ainda na sua classe separada? O JPanel implementação MouseListener em uma classe interna? E por quê?

A coisa mais importante para mim é que ele funciona, mas eu gostaria de conhecer e compreender as práticas padrão por trás dessas coisas, se possível.

EDIT:. Versão do código atual Muito simplificado abaixo

class ControllerWindow extends JFrame{
    ...
    MapPanel drawPanel = new MapPanel();
    ...
}

e uma classe separada:

class MapPanel extends JPanel implements MouseListener{

    ...

    public void paintComponent(Graphics g){
        ...//fillRects etc.
    }

    //MouseListener methods
    public void mouseReleased(MouseEvent e){
        requestFocus();
        ...
        repaint()
        ...
    }
    public void mousePressed(MouseEvent e){}
    public void mouseEntered(MouseEvent e){}
    public void mouseExited(MouseEvent e){}
    public void mouseClicked(MouseEvent e){}
}

Além disso, este poderia ser uma situação onde seria aceitável para colocar ambas as classes no mesmo arquivo? Eu não tencionam utilizar MapPanel para outra coisa senão ControllerWindow.

Answer 1

Eu acho que é um pouco arbitrária como você vai fazer sobre isso (como Tom Hawtin comentou, padrões GUI = lama), desde que você está negociando off complexidade no número de classes contra complexidade em uma única classe. Se você quiser produzir código simplesmente para uma demonstração, um único arquivo pode ser mais fácil. Se você quiser código que você está indo para colocar em produção e modificar / manter ao longo do tempo, abstraindo-se em diferentes classes é quase certamente a maneira que você quer ir.

Por exemplo, se você incorporar MapPanel como uma classe interna em ControllerWindow, e depois quer substituí-lo por um tipo diferente de MapPanel, você tem uma grande atualização para ControllerWindow ao invés de apenas trocar MapPanel para um componente diferente tipo.

Com a MouseListener, eu estaria inclinado a incluí-lo em MapPanel se ele está lidando com eventos especificamente para esse componente (isto é, se apenas o MapPanel "sabe" o que significa um clique, ele deve ser o único a processar esse clique ). Eu definitivamente não iria colocá-lo em ControllerWindow, desde então você está "vazando" detalhe de implementação de MapPanel. (O único caso que eu posso pensar: para além da sua MapPanel, você tem múltipla tipo painéis que todos precisam responder a cliques da mesma forma, então em vez de implementar em cada painel você poderia ter o ControllerWindow fazê-lo Mas, mesmo assim. , eu não estou certo do código deve estar em ControllerWindow).

ouvinte do mouse é se MapPanel é uma implementação classe interna de MouseListener, ou se MapPanel implementa-lo (como no seu código acima) provavelmente se resume a uma questão de qual estilo você prefere.

Answer 2

É comum o uso de classes internas anônimas como ouvintes de eventos porque o código é geralmente bastante simples (para uma classe separada pode ser um exagero) e mantendo o código do manipulador de "fechar" para o código que registra o ouvinte pode melhorar a legibilidade para pessoas tentando entender o seu código, uma vez que todo o código relacionado com o evento é em um lugar.

EDIT: Isto é particularmente verdadeiro para as classes que implementam apenas um método ouvinte. Talvez menos verdadeiro para interfaces multi-método como MouseListener, desde uma classe que implementa a interface completa será mais detalhado.

Answer 3

classe interna seria melhor se ele tem uma sintaxe mais simples.

button1.click( function(event){ do something x...  } );
button2.click( function(event){ do something y...  } );
radio2.check ( function(event){ do something z... } );

java 7 pode nos dar algo assim e mudar toda a situação. como é agora, usando um monte de annonymous classes internas pode atrapalhar o código e torná-lo impossível de ler. você deve escolher o estilo que faz o seu código bonita e legível.

Answer 4

Por causa de múltiplos requisitos de manipulação de eventos classes internas anônimas são obrigatórios. classe anônima pode ser escrito em qualquer lugar como em uma classe, em um método, no argumento. Portanto, para se abster de criar muitas classes para cada ouvinte anônimo é o preferido.

Answer 5

Eu encontrei este artigo útil: http://www.retrologic.com/innerclasses.doc3.html

Em geral, quando você precisa usar um ponteiro método; estender as classes adaptadoras como classes internas para simplificar o seu código.