Extiende JFrame versus crearlo dentro del programa
Al crear una aplicación usando Swing, he visto a 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);
}
}
Pensamientos:
- Evite extender JFrame ya que vincula su GUI a ser, bueno, un JFrame. Si, en cambio, se concentra en crear JPanels, entonces tendrá la libertad de usar estos JPanels en cualquier lugar que necesite: en un JFrame, JDialog, JApplet, o dentro de otro JPanel, o intercambiándolos con otros JPanels a través de un CardLayout.
- Evite la herencia en general, especialmente de clases complejas. Esto evitará errores perniciosos, como anulaciones involuntarias de métodos (intente crear un JFrame o JPanel que tenga un método
getX()ygetY()para ver a qué me refiero). - Evite la herencia de clases complejas si está utilizando un IDE: si anula una clase compleja, cuando llame a métodos en objetos de estas clases, se le ofrecerán muchas, demasiadas opciones de métodos.
- La encapsulación es buena, lo es y permite la creación de código más seguro. Exponga sólo lo que necesita ser expuesto y controle esa exposición tanto como sea posible.
Prefiere la composición a la herencia .
El segundo ejemplo usa herencia, pero sin una buena razón, ya que no cambia la funcionalidad de JFrame.
Además, si esos son ejemplos de código que está viendo, busque una nueva fuente 1 complementaria . Incluso en las pocas líneas de código que se muestran, cada una hace cosas muy cuestionables. P.EJ
- Ninguna GUI se crea en el hilo de envío de eventos.
getContentPane().setBackground(Color.WHITE); getContentPane().setLayout(null); setSize(800, 600);- La primera parte de la 1.ª línea (
getContentPane()) no es necesaria desde Java 1.5 - La segunda línea utiliza un
nulldiseño, que se dividirá en más formas que puedo contar o describir. - Es mejor reemplazar la tercera línea con
pack();
- La primera parte de la 1.ª línea (
JFrame guiFrame = new JFrame(); guiFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); guiFrame.setTitle("Example GUI"); guiFrame.setSize(300,250);- La primera y tercera línea podrán contratarse para:
JFrame guiFrame = new JFrame("Example GUI"); - Es mejor configurar la segunda línea en
guiFrame.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); - La tercera línea vuelve a establecer un tamaño para el marco.
- La primera y tercera línea podrán contratarse para:
Suplemento
- Habiendo mencionado que busca SO, aquí tiene un consejo. Consulte las publicaciones de los 15 principales proveedores de respuestas en los principales usuarios de Swing . Cualquier consejo/código que obtenga de estas personas, cometería pocos o ninguno de los errores en esos ejemplos de código.
Algunos no proporcionan a menudo (o nunca) ejemplos autónomos como lo hacemos habitualmente algunos de nosotros (y no miramos esos ejemplos necesariamente para el diseño OO en lugar de simplemente para la técnica), pero cualquier código que proporcionen o consejos que den , debe ser muy considerado.
Personalmente, se prefiere el primer enfoque (crear una instancia de JFrame), prefiero este porque...
No bloquea su aplicación en un contenedor dedicado... ve a muchas personas que quieren agregar subprogramas a marcos y marcos a subprogramas, si simplemente hubieran puesto la mayoría de la GUI en un para empezar JPanel, no lo harían. No tengo estos problemas.
También significa que la interfaz de usuario que crea es mucho más flexible. Por ejemplo, puedes reutilizarlo, ya sea en la aplicación actual o en aplicaciones futuras, no te encierras.
La principal queja que tengo con la extensión JFramees que en realidad no le estás agregando ninguna característica o funcionalidad nueva, que podría reutilizarse de manera efectiva más allá de usarsetVisible
El otro problema que tengo con la extensión JFramees que la gente luego anula rápidamente paint, lo cual es realmente malo. Hay tantos problemas al hacer esto que es simplemente doloroso tener que enumerarlos repetidamente...
Entonces... por más de 2 centavos. Cree una instancia JFramey agréguele su contenido. Si es necesario, cree una staticllamada a un método showMyAwesomeGUIque lo haga por usted...
El primer enfoque es mejor.
Normalmente no se agrega ninguna funcionalidad nueva al marco, por lo que tiene sentido crear una instancia directa de la clase.
Opte por el primer enfoque.
Porque con eso puedes tener más cuadros por crear. Porque la aplicación puede tener más de una ventana. Como en el segundo caso, no puedes crear más fotogramas.
