Kiedy powinienem rozszerzyć klasę Java Swing?

Moje obecne rozumienie implementacji dziedziczenia jest takie, że należy rozszerzać klasę tylko wtedy, gdy istnieje relacja IS-A . Jeśli klasa nadrzędna może dodatkowo mieć bardziej szczegółowe typy podrzędne o różnych funkcjach, ale będzie miała wspólne elementy wyodrębnione w obiekcie nadrzędnym.

Kwestionuję to zrozumienie z powodu tego, co zaleca nam mój profesor Java. Zalecił, aby w przypadku JSwingaplikacji budowanej w klasie

Należy rozszerzyć wszystkich JSwingklas ( JFrame, JButton, JTextBox, etc) do oddzielnych klas niestandardowych i określić dostosowanie GUI powiązane w nich (podobnie jak wielkość składnika, etykiety komponentów, etc)

Jak dotąd jest tak dobry, ale dalej radzi, aby każdy JButton miał własną niestandardową rozszerzoną klasę, chociaż jedynym wyróżnikiem jest jej etykieta.

Na przykład jeśli GUI ma dwa przyciski OK i Anuluj . Zaleca przedłużenie ich jak poniżej:

class OkayButton extends JButton{
    MainUI mui;
    public OkayButton(MainUI mui) {
        setSize(80,60);
        setText("Okay");
        this.mui = mui;
        mui.add(this);        
    }
}

class CancelButton extends JButton{
    MainUI mui;
    public CancelButton(MainUI mui) {
        setSize(80,60);
        setText("Cancel");
        this.mui = mui;
        mui.add(this);        
    }
}

Jak widać jedyną różnicą jest setTextfunkcja.

Więc czy to standardowa praktyka?

Btw, kurs, w którym to omówiono, nazywa się Najlepszymi praktykami programowania w Javie

[Odpowiedź od prof]

Omówiłem więc problem z profesorem i podniosłem wszystkie punkty wymienione w odpowiedziach.

Jego uzasadnieniem jest to, że podklasa zapewnia kod wielokrotnego użytku przy zachowaniu standardów projektowania GUI. Na przykład, jeśli programista użył przycisków niestandardowych Okayi Cancelprzycisków w jednym oknie, łatwiej będzie umieścić te same przyciski również w innych oknach.

Wydaje mi się, że mam powód, ale wciąż wykorzystuje dziedziczenie i sprawia, że ​​kod jest kruchy.

Później każdy programista mógł przypadkowo wywołać setTextna Okayprzycisk i zmienić go. W takim przypadku podklasa staje się po prostu uciążliwa.

Jest to niezgodne z zasadą substytucji Liskowa, ponieważ OkayButtonnie można go zastąpić w żadnym miejscu, w którym Buttonmożna się spodziewać. Na przykład możesz zmienić etykietę dowolnego przycisku, jak chcesz. Ale robienie tego przy OkayButtonnaruszeniu wewnętrznych niezmienników.

Jest to klasyczne niewłaściwe użycie dziedziczenia do ponownego użycia kodu. Zamiast tego użyj metody pomocniczej.

Innym powodem, aby tego nie robić, jest to, że jest to po prostu skomplikowany sposób osiągnięcia tego samego, co zrobiłby kod liniowy.

Jest to całkowicie okropne pod każdym możliwym względem. W najwyżej użyj funkcji fabrycznej, aby utworzyć JButtons. Powinieneś dziedziczyć po nich tylko wtedy, gdy potrzebujesz poważnych rozszerzeń.

Jest to bardzo niestandardowy sposób pisania kodu Swing. Zazwyczaj rzadko tworzysz podklasy składników Swing UI, najczęściej JFrame (w celu skonfigurowania okien potomnych i programów obsługi zdarzeń), ale nawet ta podklasa jest niepotrzebna i wielu odradza. Zapewnianie dostosowywania tekstu do przycisków i tak dalej jest zwykle wykonywane przez rozszerzenie klasy AbstractAction (lub interfejsu Action, który zapewnia). Może to zapewnić tekst, ikony i inne niezbędne dostosowania wizualne oraz połączyć je z rzeczywistym kodem, który reprezentują. Jest to o wiele lepszy sposób pisania kodu interfejsu użytkownika niż pokazywane przykłady.

(przy okazji, Google Scholar nigdy nie słyszał o cytowanym przez siebie artykule - czy masz bardziej precyzyjne odniesienie?)

IMHO, najlepsze praktyki programowania w Javie są zdefiniowane w książce Joshua Blocha „Effective Java”. To wspaniale, że twój nauczyciel daje ci ćwiczenia OOP i ważne jest, aby nauczyć się czytać i pisać style programowania innych ludzi. Ale poza książką Josha Blocha opinie na temat najlepszych praktyk różnią się znacznie.

Jeśli zamierzasz rozszerzyć tę klasę, równie dobrze możesz skorzystać z dziedziczenia. Utwórz klasę MyButton, aby zarządzać wspólnym kodem i podklasuj go dla części zmiennych:

class MyButton extends JButton{
    protected final MainUI mui;
    public MyButton(MainUI mui, String text) {
        setSize(80,60);
        setText(text);
        this.mui = mui;
        mui.add(this);        
    }
}

class OkayButton extends MyButton{
    public OkayButton(MainUI mui) {
        super(mui, "Okay");
    }
}

class CancelButton extends MyButton{
    public CancelButton(MainUI mui) {
        super(mui, "Cancel");
    }
}

Kiedy to jest dobry pomysł? Kiedy korzystasz z typów, które stworzyłeś! Na przykład, jeśli masz funkcję tworzenia wyskakującego okna, a sygnatura to:

public void showPopUp(String text, JButton ok, JButton cancel)

Te typy, które właśnie utworzyłeś, nie przynoszą żadnego pożytku. Ale:

public void showPopUp(String text, OkButton ok, CancelButton cancel)

Teraz stworzyłeś coś przydatnego.

1. Kompilator sprawdza, czy showPopUp przyjmuje OkButton i CancelButton. Ktoś czytający kod wie, jak ma być używana ta funkcja, ponieważ tego rodzaju dokumentacja spowoduje błąd kompilacji, jeśli przestanie być aktualny. Jest to GŁÓWNA korzyść. W 1 lub 2 badaniach empirycznych dotyczących korzyści bezpieczeństwa typu stwierdzono, że zrozumienie kodu ludzkiego było jedyną wymierną korzyścią.

2. Zapobiega to również błędom w przypadku odwrócenia kolejności przycisków przekazywanych do funkcji. Błędy te są trudne do wykrycia, ale są również dość rzadkie, więc jest to MNIEJSZA korzyść. Zostało to wykorzystane do sprzedaży bezpieczeństwa typu, ale nie zostało udowodnione empirycznie, że jest szczególnie przydatne.

3. Pierwsza forma funkcji jest bardziej elastyczna, ponieważ wyświetla dwa dowolne przyciski. Czasami jest to lepsze niż ograniczanie, jakiego rodzaju przycisków zajmie. Pamiętaj tylko, że musisz przetestować funkcję dowolnego przycisku w większej liczbie przypadków - jeśli działa ona tylko wtedy, gdy przekażesz jej dokładnie odpowiedni rodzaj przycisków, nie zrobisz nikomu przysługi, udając, że zajmie ona jakikolwiek przycisk.

Problem z programowaniem obiektowym polega na tym, że stawia wózek przed koniem. Musisz najpierw napisać funkcję, aby wiedzieć, co ma wiedzieć podpis, jeśli warto tworzyć dla niego typy. Ale w Javie musisz najpierw utworzyć typy, aby móc napisać podpis funkcji.

Z tego powodu możesz chcieć napisać kod Clojure, aby zobaczyć, jak wspaniale może być napisanie najpierw twoich funkcji. Możesz pisać szybko, myśląc o asymptotycznej złożoności tak bardzo, jak to możliwe, a założenie o niezmienności Clojure zapobiega błędom tak bardzo, jak robią to typy w Javie.

Nadal jestem fanem typów statycznych dla dużych projektów, a teraz używam narzędzi funkcjonalnych, które pozwalają mi najpierw pisać funkcje, a później nazwać moje typy w Javie . Tylko myśl.

PS muiUczyniłem wskaźnik końcowym - nie musi być zmienny.

Byłbym skłonny założyć się, że twój nauczyciel tak naprawdę nie wierzy, że zawsze powinieneś przedłużać komponent Swing, aby go użyć. Założę się, że wykorzystują to jako przykład, aby zmusić cię do ćwiczenia przedłużania zajęć. Na razie nie martwiłbym się zbytnio najlepszymi praktykami w świecie rzeczywistym.

To powiedziawszy, w prawdziwym świecie wolimy kompozycję niż dziedziczenie .

Twoja reguła „należy rozszerzać klasę tylko wtedy, gdy istnieje relacja IS-A” jest niepełna. Powinien kończyć się „... i musimy zmienić domyślne zachowanie klasy” dużymi pogrubionymi literami.

Twoje przykłady nie spełniają tych kryteriów. Nie masz do extendtej JButtonklasy po prostu ustawić swój tekst. Nie masz do extendtej JFrameklasy tylko dodać elementy do niego. Możesz zrobić te rzeczy dobrze, używając ich domyślnych implementacji, więc dodanie dziedziczenia to tylko niepotrzebne komplikacje.

Jeśli zobaczę klasę extendsinnej klasy, zastanawiam się, co się zmienia . Jeśli niczego nie zmieniasz, nie zmuszaj mnie wcale do przeglądania klasy.

Powrót do pytania: kiedy należy rozszerzyć klasę Java? Kiedy masz naprawdę, naprawdę, naprawdę dobry powód, aby przedłużyć klasę.

Oto konkretny przykład: jednym ze sposobów wykonania niestandardowego malowania (dla gry lub animacji, lub tylko dla niestandardowego komponentu) jest rozszerzenie JPanelklasy. (Więcej informacji na ten temat tutaj .) Można rozszerzyć JPanelklasę, bo trzeba zastąpić na paintComponent()funkcję. W ten sposób zmieniasz zachowanie klasy . Nie można wykonać niestandardowego malowania z domyślną JPanelimplementacją.

Ale tak jak powiedziałem, twój nauczyciel prawdopodobnie używa tych przykładów jako wymówki, aby zmusić cię do ćwiczenia przedłużania zajęć.