java - when - oop patterns

Extiende JFrame contra crearlo dentro del programa

Question

Al hacer una aplicación usando Swing, he visto personas hacer una de las dos cosas para crear un JFrame. ¿Cuál es un mejor enfoque y por qué?

Soy un principiante en Java y programación. Mi única fuente de aprendizaje son los libros, YouTube y 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);
        ................
    }

Y

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);

    }
}

Answer 1

El primer acercamiento es mejor.

Por lo general, no está agregando ninguna funcionalidad nueva al cuadro, por lo que tiene sentido crear una instancia directa de la clase.

Answer 2

No importa.

Hay razones por las que puede hacer una u otra, pero sin ninguna de esas razones, no hace diferencia alguna.

Ahora, si estuvieras escribiendo algo que podría operar desde la línea de comandos o podría ser un programa de GUI, obviamente podrías querer una clase ''principal'' que no fuera una clase de GUI.

Si trabajó en una tienda de programación donde uno u otro era el estándar, siga todos los estándares. No hay una respuesta correcta para esto, y de hecho muy poco para elegir entre ellos.

Answer 3

Pensamientos:

• Evita extender JFrame porque ata tu GUI a ser, bueno, un JFrame. Si por el contrario te concentras en crear JPanels en su lugar, entonces tienes la libertad de usar estos JPanels en cualquier lugar que necesites: en JFrame, JDialog o JApplet, o dentro de otro JPanel, o intercambiados con otros JPanels a través de CardLayout.
• Evite la herencia en general, especialmente de clases complejas. Esto evitará errores perniciosos, como anulaciones de métodos inadvertidos (intente crear un JFrame o JPanel que tenga un getX() y getY() para ver lo que quiero decir!).
• Evite la herencia de clases complejas si está utilizando un IDE: si anula una clase compleja, cuando llama a métodos en objetos de estas clases, tendrá muchas, demasiadas opciones de métodos que se le ofrecen.
• La encapsulación es buena, es y permite la creación de un código más seguro. Exponga solo aquello que necesita estar expuesto, y controle esa exposición tanto como sea posible.

Answer 4

Personalmente, se prefiere el primer enfoque (crear una instancia de JFrame ), prefiero esto porque ...

No bloquea tu aplicación en un contenedor dedicado ... ves a mucha gente que quiere agregar applets a marcos y marcos a applets, si hubieran puesto la mayoría de GUI en un JPanel para empezar, no lo harían. No tengo estos problemas.

También significa que la UI que creas es mucho más flexible. Por ejemplo, puede reutilizarlo, ya sea en la aplicación actual o en aplicaciones futuras, no se puede encerrar.

La principal queja que tengo con la extensión de JFrame es que, en realidad, no está agregando ninguna característica o funcionalidad nueva, que podría ser reutilizada efectivamente más allá del uso de setVisible

El otro problema que tengo con la extensión de JFrame es que la gente inmediatamente invalida la paint , lo que es realmente, realmente malo. Hay tantos problemas para hacer esto que es simplemente doloroso tener que enumerarlos repetidamente ...

Entonces ... por más 2 centavos vale la pena. Crea una instancia de JFrame y agrega tu contenido a ella. Si es necesario, crea una llamada al método static showMyAwesomeGUI que lo haga por ti ...

Answer 5

Prefiere la composición sobre la herencia .

El segundo ejemplo usa herencia, pero sin una buena razón, ya que no cambia la funcionalidad de JFrame .

Como un aparte, si esos son ejemplos de código que está viendo, busque una fuente nueva ^{1 suplementaria} . Incluso en las pocas líneas de código que se muestran, cada uno hace cosas altamente cuestionables. P.EJ

1. Ninguna GUI se crea en el hilo de envío del evento.
2. getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);
   • La primera parte de la primera línea ( getContentPane() ) no ha sido necesaria desde Java 1.5
   • La segunda línea utiliza un diseño null , que se dividirá en más formas que puedo contar o describir.
   • La tercera línea debería ser reemplazada por pack();
3. JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);
   • La primera y la tercera líneas podrían ser contratadas para:
     JFrame guiFrame = new JFrame("Example GUI");
   • La segunda línea se configura mejor en guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
   • La tercera línea nuevamente establece un tamaño para el marco.

Suplemento

1. Habiendo mencionado que busca SO, aquí hay un consejo. Consulte las publicaciones de los 15 principales proveedores de respuestas en los principales usuarios de Swing . Cualquiera sea el consejo / código que obtenga de estas personas, cometerá pocos o ninguno de los errores en esas muestras de código.
   
   Algunos no suelen (o nunca) proporcionan ejemplos autónomos, como algunos de nosotros lo hacemos comúnmente (y no buscan esos ejemplos necesariamente para el diseño OO en oposición a solo la técnica), pero cualquiera que sea el código que proporcionan, o el consejo que dan , debe ser muy bien considerado.

Answer 6

Ve por el primer acercamiento.

Porque con eso puedes tener más marcos para crear. Porque la aplicación puede tener más de una ventana. Como en el segundo caso, no puedes crear más cuadros.