2011-08-06 10 views
7

Tengo una clase digamos MyJFrame que representa la GUI de mi aplicación. Implementa la interfaz Observer y anula el método update.Hacer un JFrame y Objeto Observable

public class MyJFrame extends JFrame implements Observer{ 
    ... 
    public void update(Observable arg0, Object arg1){ 
    ... 
    } 
} 

Ahora me quieren hacer también mi JFram un objeto observable pero no se puede porque ya extender la clase JFrame. Intenté crear una variable de tipo Observable en mi clase.

public class MyJFrame extends JFrame implements Observer{ 
    Observable observable = new Observable(); 

El problema aquí es que puedo añadir Observador en este campo observable y también puedo notificar al observador pero no puedo invocar el método setChanghed() (porque se ha declarado como protegido), que tiene que ser llamado antes de la notificación .

¿Tiene alguna idea sobre cómo puedo implementarlo?

Gracias!

Respuesta

3

Extienda Observable y declare setChanged() público.

+0

¿Puede ser más detallado, por favor? ¡Gracias! – Maverik

+2

Al extender una clase, puede volver a declarar sus métodos con un modificador de visibilidad que es más alto de lo que era anteriormente. Dado que 'Observa's' setChanged() 'estaba protegido, puede crear una subclase de' Observable' con 'setChanged()' siendo pública. – Jeffrey

+1

No estoy de acuerdo, pero estaba seguro de que no era posible modificar la visibilidad de un método. Gracias, funciona! – Maverik

6

Creo que muchos aquí, incluido yo mismo uso el Observer Design Pattern sin utilizar la interfaz/clase formal de Java Observer/Observable, y hay muchas maneras de implementar esto, especialmente en Swing. Probablemente el más flexible es usar PropertyChangeSupport con PropertyChangeListeners, que es como SwingWorkers implementa esto. Otra es usar la interfaz ChangeListener muy básica.

Si necesita ayuda más específica, proporcione más detalles sobre su problema y es probable que podamos ofrecerle sugerencias.

Editar 1
Esto también se posa sobre un tema aparte, pero importante, que está sugerida por la descripción de su programa: la clase de interfaz gráfica de usuario que se extiende JFrame. Muchos aquí (una vez más incluido) recomiendan que evite hacer esto a menos que su código modifique el comportamiento intrínseco de JFrame, es decir, su clase anula uno o más de los métodos de JFrame. Esta es una pequeña sub-discusión en la discusión mucho mayor sobre cuál es mejor: mejorar las clases a través de la herencia o mediante la composición.

Por ejemplo: Prefer composition over inheritance?

Editar 2
recomendación no solicitada siguiente: Trato de engranajes mi código de interfaz gráfica de usuario hacia la creación de JPanels en lugar de JFrames. De esta forma, si quiero mostrar mi GUI como una GUI independiente, simplemente creo un JFrame sobre la marcha, coloco el JPanel de mi gui en el panel de contenido de JFrame, empaco el JFrame y lo visualizo. Hago el mismo procedimiento si quiero colocar la GUI en un JDialog, un JApplet, un JOptionPane, o también en un CardLayout usando contenedor, otro JPanel, .... Esto me da una gran flexibilidad en la forma en que uso mi GUI.

+0

¿Entonces dices que si quiero hacer una GUI es mejor declarar JFrame como una variable de mi clase y usarlo? – Maverik

+1

PropertyChangeListeners + SwingWorkers, en lugar de Observable +1 – mKorbel

+0

@lucaghera: No puedo decir qué es mejor para su situación con el 100% de precisión, pero a mí mismo prefiero no extender JFrame si puedo evitar hacerlo y generalmente soy exitoso al hacer esta. –

2

Esto lo hará.

public class MyJFrame extends JFrame implements Observer { 
    private static class MyObservable extends Observable { 
     @Override 
     public void setChanged() { 
      super.setChanged(); 
     } 
    } 
    private final MyObservable observable = new MyObservable(); 

    // rest of your code 
} 
+1

tal vez sea correcto para OP, pero creo que para esta implementación las salidas a la GUI debe estar envuelta en invokeAndWait(), – mKorbel

Cuestiones relacionadas