2011-08-06 11 views
7

Mam klasę powiedzmy MyJFrame, które reprezentują GUI mojej aplikacji. Implementuje interfejs Observer i zastępuje metodę.Tworzenie obiektu JFrame i Observable

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

Teraz chcę, aby także mój JFram obserwowanej obiektu, ale nie mogę, bo to już rozszerzyć klasę JFrame. Próbowałem utworzyć zmienną typu Observable w mojej klasie.

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

Problemem jest to, że mogę dodać obserwator tej obserwowanej dziedzinie i mogę również zawiadomić obserwatora, ale nie mogę wywołać metodę setChanghed() (ponieważ jest zadeklarowana jako chroniona), który musi być wywołana przed zgłoszeniem .

Czy masz pojęcie, czy mogę to wdrożyć?

Dzięki!

Odpowiedz

3

Przedłuż Observable i zadeklaruj publiczną nazwę setChanged().

+0

Czy możesz być bardziej szczegółowy proszę? Dzięki! – Maverik

+2

Po rozszerzeniu klasy można redeclare jego metod za pomocą modyfikatora widoczności, który jest wyższy niż poprzednio. Ponieważ 'Observable's' setChanged() 'był chroniony, możesz utworzyć podklasę' Observable' z 'setChanged()' będącą publiczną. – Jeffrey

+1

Nie mam teraz sposobu, ale byłem pewien, że nie było możliwe modyfikowanie widoczności metody. Dzięki, działa! – Maverik

6

Myślę, że wielu tutaj, ja sam użyłem Observer Design Pattern bez korzystania z interfejsu Javy, oficjalnego interfejsu Observer/Observable i istnieje wiele sposobów na jego wdrożenie, szczególnie w Huśtawce. Prawdopodobnie najbardziej elastyczne jest użycie PropertyChangeSupport z PropertyChangeListeners, w jaki sposób SwingWorkers to zaimplementuje. Innym jest użycie bardzo podstawowego interfejsu ChangeListener.

Jeśli potrzebujesz bardziej szczegółowej pomocy, podaj więcej szczegółów na temat problemu i prawdopodobnie możemy zaproponować.

Edycja 1
Ten alights także na odrębnej ale ważnej kwestii, która jest sugerowane przez opis programu: klasa GUI rozciągającej JFrame. Wielu tutaj (włączając mnie ponownie) zaleca, aby unikać tego, chyba że twój kod zmienia wewnętrzne zachowanie JFrame - to znaczy, że twoja klasa zastępuje jedną lub więcej metod JFrame'a. Jest to mała pod-dyskusja w znacznie większej dyskusji, która jest lepsza: ulepszanie klas poprzez dziedziczenie lub poprzez kompozycję.

Na przykład: Prefer composition over inheritance?

Edycja 2
Następny Niepożądany zalecenie: Staram się bieg mojego kodu GUI w kierunku tworzenia JPanels zamiast JFrames. W ten sposób, jeśli chcę wyświetlać GUI jako samodzielny GUI, po prostu tworzę JFrame w locie, umieszczam JPanel mojego gui w JFrame's contentPane, pakuję JFrame i wyświetlam go. Robię tę samą procedurę, jeśli chcę umieścić gui w JDialog, JApplet, JOptionPane lub w CardLayout używając kontenera, innego JPanela, .... Daje mi to ogromną elastyczność w posługiwaniu się moim gui.

+0

Mówisz, że jeśli chcę zrobić GUI, lepiej jest zadeklarować JFrame jako zmienną mojej klasy i użyć jej? – Maverik

+1

PropertyChangeListeners + SwingWorkers, zamiast Observable +1 – mKorbel

+0

@lucaghera: Nie mogę powiedzieć, co jest lepsze dla twojej sytuacji ze 100% celnością, ale ja wolę nie rozszerzać JFrame, jeśli mogę tego uniknąć i zwykle robię to z powodzeniem to. –

2

To zrobi to.

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

może poprawne dla OP, ale tam myślę, że dla tego wykonania implementacji do GUI musi być zawinięty w invokeAndWait(), – mKorbel