DoCow
  1. DoCow
  3. Estende JFrame vs criando dentro do programa

Estende JFrame vs criando dentro do programa

Ao criar um aplicativo usando o Swing, vi pessoas fazerem uma das duas coisas para criar um JFrame. Qual é a melhor abordagem e por quê?

Sou iniciante em Java e programação. Minha única fonte de aprendizado são livros, YouTube e Stack Overflow. 

import {imports}; public class GuiApp1 { public static void main(String[] args) { new GuiApp1(); } public GuiApp1() { JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250); ................ }

E 

 import {imports}; public class GuiApp1 extends JFrame { public Execute() { getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600); ............. } public static void main(String[] args) { Execute frame1 = new Execute(); frame1.setVisible(true); } }

Pensamentos:

  • Evite estender o JFrame, pois ele vincula sua GUI a ser, bem, um JFrame. Se, em vez disso, você se concentrar em criar JPanels, terá a liberdade de usar esses JPanels em qualquer lugar necessário – em um JFrame, JDialog ou JApplet, ou dentro de outro JPanel, ou trocados por outros JPanels por meio de um CardLayout.
  • Evite a inheritance em geral, especialmente de classs complexas. Isso evitará erros perniciosos, como substituições de methods inadvertidas (tente criar um JFrame ou JPanel que tenha um getX() e getY() para ver o que quero dizer!).
  • Evite a inheritance de classs complexas se você estiver usando um IDE: Se você replace uma class complexa, quando você chamar methods em objects dessas classs, você terá muitas, muitas opções de methods oferecidas a você.
  • Encapsulamento é bom, é e permite a criação de código seguro. Exponha apenas aquilo que precisa ser exposto e controle a exposição o máximo possível.

Prefiro composição sobre inheritance .

O segundo exemplo usa inheritance, mas sem um bom motivo, já que não altera a funcionalidade do JFrame .

Como um aparte, se esses são exemplos de código que você está vendo, encontre uma nova fonte 1 suplementar . Mesmo nas poucas linhas de código mostradas, cada uma delas faz coisas altamente questionáveis. POR EXEMPLO

  1. Nenhuma GUI é criada no encadeamento de expedição de events.
  2. getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);
    • A primeira parte da primeira linha ( getContentPane() ) não é necessária desde o Java 1.5
    • A segunda linha usa um layout null , que irá quebrar em mais maneiras que eu posso contar ou descrever.
    • A terceira linha deve ser melhor substituída por pack();
  3. JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);
    • A primeira e terceira linhas podem ser contratadas para:
      JFrame guiFrame = new JFrame("Example GUI");
    • A segunda linha é melhor definida como guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    • A terceira linha novamente define um tamanho para o quadro.

Suplemento

  1. Tendo mencionado que você procura SO, aqui está uma dica. Confira as postagens dos 15 principais provedores de respostas nos principais usuários do Swing . Qualquer que seja o conselho / código que você obtiver dessas pessoas, cometerá poucos ou nenhum dos erros nessas amostras de código.

    Alguns não costumam (ou nunca) fornecem exemplos auto-contidos como alguns de nós geralmente fazem (e não olham para esses exemplos necessariamente para design OO em vez de apenas técnica), mas qualquer que seja o código que eles forneçam ou conselhos , deve ser altamente considerado.

Pessoalmente, a primeira abordagem (criando uma instância do JFrame ) é a preferida, eu prefiro isso porque …

Ele não bloqueia seu aplicativo em um contêiner dedicado … você vê um monte de pessoas querendo adicionar applets a frameworks e frameworks para applets, se eles tivessem simples colocar a maioria de lá GUI em um JPanel para começar, eles wouldn não tem esses problemas.

Isso também significa que a interface do usuário que você cria é muito mais flexível. Por exemplo, você pode reutilizá-lo, seja no aplicativo atual ou em futuros aplicativos, não se trancando nele.

A principal reclamação que tenho com a extensão do JFrame é que você não está realmente adicionando nenhum novo recurso ou funcionalidade a ele, que pode ser efetivamente reutilizado além do uso de setVisible

O outro problema que tenho com a extensão do JFrame é que as pessoas logo sobrescrevem a paint , o que é realmente muito ruim. Existem tantos problemas ao fazer isso que é simplesmente doloroso ter que listá-los repetidamente …

Então … por mais 2 centavos de valor. Crie uma instância do JFrame e adicione seu conteúdo a ela. Se necessário, crie um método static chamada showMyAwesomeGUI que faz isso para você …

A primeira abordagem é melhor.

Normalmente, você não está adicionando nenhuma nova funcionalidade ao quadro, portanto, criar uma instância direta da class faz sentido.

Vá para a primeira abordagem.

Porque com isso você pode ter mais frameworks a serem criados. Porque o aplicativo pode ter mais de uma janela. Como no segundo caso, você não pode criar mais frameworks.

Isso não importa.

Existem razões pelas quais você pode fazer uma ou outra, mas sem nenhuma dessas razões, não faz diferença alguma.

Agora, se você estivesse escrevendo algo que pudesse operar a partir da linha de comando ou poderia ser um programa GUI, obviamente você poderia querer uma class ‘main’ que não fosse uma class GUI.

Se você trabalhou em uma loja de programação onde um ou outro era o padrão, siga o padrão. Não há resposta certa para esta, e de fato muito pouco para escolher entre elas.

Intereting Posts