Коли я повинен розширити клас Java Swing?

Моє сучасне розуміння реалізації Успадкування полягає в тому, що слід розширювати клас лише тоді, коли є відношення IS-A . Якщо батьківський клас може додатково мати більш конкретні дочірні типи з різною функціональністю, але вони матимуть спільні елементи, абстраговані у батьків.

Я ставлю під сумнів це розуміння через те, що рекомендує нам робити мій професор Java. Він порекомендував для JSwingпрограми, яку ми будуємо на уроці

Необхідно розширити всі JSwingкласи ( JFrame, JButton, JTextBox, і т.д.) в окремі призначені для користувача класи і вказати GUI відповідного налаштування в них (наприклад , розмір компонента, мітки компонента, і т.д.)

Поки що добре, але далі він радить, що кожен JButton повинен мати власний розширений клас, хоча єдиним відмінним фактором є їх марка.

Наприклад, якщо у GUI є дві кнопки Гаразд та Скасувати . Він рекомендує розширити їх, як зазначено нижче:

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

Як бачите, єдина різниця полягає у setTextфункції.

Так це стандартна практика?

До речі, курс, де це обговорювалося, називається Кращі практики програмування на Java

[Відповідь професора]

Тож я обговорив проблему з професором і підняв усі моменти, згадані у відповідях.

Його виправданням є те, що підкласифікація надає код для багаторазового використання, дотримуючись стандартів дизайну GUI. Наприклад, якщо розробник використовував користувацькі Okayта Cancelкнопки в одному вікні, буде зручніше розмістити ті самі кнопки і в інших Windows.

Я маю на увазі причину, але все-таки це просто використання спадщини та надання коду тендітним.

Пізніше будь-який розробник може випадково зателефонувати setTextна Okayкнопку та змінити її. Підклас просто стає неприємним у такому випадку.

Це порушує Принцип заміщення Ліскова, оскільки не OkayButtonможе бути замінено місце в будь-якому місці Button. Наприклад, ви можете змінити мітку будь-якої кнопки за вашим бажанням. Але робити це з OkayButtonпорушенням його внутрішніх інваріантів.

Це класичне неправильне використання спадщини для повторного використання коду. Використовуйте замість цього хелперний метод.

Ще одна причина цього не робити - це лише звичний спосіб досягти того самого, що і лінійний код.

Це абсолютно страшно всіляко. У найбільш використовуйте функцію фабрики для виробництва JButtons. Ви повинні успадковувати їх лише в тому випадку, якщо у вас є серйозні потреби у продовженні.

Це дуже нестандартний спосіб написання коду Swing. Як правило, ви рідко створюєте підкласи компонентів Swing UI, найчастіше JFrame (для того, щоб налаштувати дочірні вікна та обробники подій), але навіть цей підклас є непотрібним і багатьом не рекомендує. Забезпечення налаштування тексту на кнопки та інше зазвичай виконується шляхом розширення класу AbstractAction (або інтерфейсу Action, який він надає). Це може забезпечити текст, піктограми та інші необхідні візуальні налаштування та зв’язати їх із фактичним кодом, який вони представляють. Це набагато кращий спосіб написання коду інтерфейсу, ніж показані вами приклади.

(до речі, вчений google ніколи не чув про цитований вами документ - у вас є більш точна довідка?)

IMHO, Найкращі практики програмування на Java визначені книгою Джошуа Блоха "Ефективна Java". Чудово, що ваш вчитель дає вам вправи на ООП і важливо навчитися читати та писати стилі програмування інших людей. Але поза межами книги Джоша Блоха думки щодо найкращої практики досить різняться.

Якщо ви збираєтеся розширити цей клас, ви також можете скористатися спадщиною. Створіть клас MyButton для управління загальним кодом та підклас його для змінних частин:

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

Коли це гарна ідея? Коли ви використовуєте створені типи! Наприклад, якщо у вас є функція створення спливаючого вікна, і підпис:

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

Ті типи, які ти тільки що створив, не приносять користі. Але:

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

Тепер ви створили щось корисне.

1. Компілятор перевіряє, що showPopUp приймає OkButton і CancelButton. Хтось, хто читає код, знає, як має бути використана ця функція, оскільки така документація призведе до помилки часу компіляції, якщо вона застаріла. Це ОСНОВНА вигода. 1 або 2 емпіричні дослідження переваг безпеки типу встановили, що розуміння коду людини є єдиною кількісно корисною користю.

2. Це також запобігає помилкам, коли ви змінюєте порядок переходу кнопок до функції. Ці помилки важко помітити, але вони також є досить рідкісними, тому це є МІНОРОЮ перевагою. Він використовувався для продажу безпеки типу, але не було емпірично доведено, що є особливо корисним.

3. Перша форма функції є більш гнучкою, оскільки вона відображатиме будь-які дві кнопки. Іноді це краще, ніж обмежувати, які кнопки будуть потрібні. Просто пам’ятайте, що вам доведеться перевірити функцію будь-якої кнопки за інших обставин - якщо вона працює лише тоді, коли ви передаєте її саме в потрібному вигляді кнопок, ви не робите нікому прихильності, роблячи вигляд, що вона буде мати будь-яку кнопку.

Проблема об'єктно-орієнтованого програмування полягає в тому, що він ставить візок перед конем. Спочатку потрібно написати функцію, щоб знати, що таке підпис, щоб знати, чи варто робити такі типи. Але в Java вам потрібно зробити свої типи спочатку, щоб ви могли написати функцію підпису.

З цієї причини ви, можливо, захочете написати якийсь код Clojure, щоб побачити, як приголомшливо спочатку написати свої функції. Ви можете швидко кодувати, максимально замислюючись про асимптотичну складність, і припущення Clojure про незмінність запобігає помилкам настільки ж, як і типи в Java.

Я все ще прихильник статичних типів для великих проектів і тепер використовую деякі функціональні утиліти, які дозволяють мені спочатку писати функції та називати свої типи пізніше на Java . Просто думка.

PS Я зробив muiпокажчик остаточним - його не потрібно змінювати.

Я хотів би зробити ставку, що ваш вчитель насправді не вірить, що ви завжди повинні розширити компонент Swing, щоб ним користуватися. Б'юсь об заклад, що вони просто використовують це як приклад, щоб змусити вас практикувати розширення занять. Я б ще не надто хвилювався про найкращі практики в реальному світі.

Як говориться, в реальному світі ми віддаємо перевагу складу над спадщиною .

Ваше правило "слід поширювати клас лише у випадку наявності співвідношення IS-A" є неповним. Він повинен закінчуватися великою жирними літерами "... і нам потрібно змінити поведінку класу за замовчуванням" .

Ваші приклади не відповідають цим критеріям. Ви не повинні extendв JButtonкласі просто встановити його текст. Ви не повинні extendв JFrameкласі просто додати компоненти. Ви можете зробити ці речі чудово, використовуючи їх за замовчуванням реалізацію, тому додавання спадщини - це просто додавання зайвих ускладнень.

Якщо я бачу клас extendsіншого класу, я буду цікавитись, що цей клас змінюється . Якщо ви нічого не змінюєте, не змушуйте мене взагалі переглядати клас.

Поверніться до свого питання: коли слід поширити клас Java? Коли у вас є справді, справді, дуже хороший привід продовжити заняття.

Ось конкретний приклад: один із способів зробити власне малювання (для гри або анімації або просто для користувальницького компонента) - розширення JPanelкласу. (Більш детальна інформація про те , що тут .) Ви продовжуєте JPanelклас , тому що вам потрібно перевизначити в paintComponent()функцію. Ви фактично змінюєте поведінку класу , роблячи це. Ви не можете виконати спеціальне малювання за допомогою програми за замовчуванням JPanel.

Але, як я вже сказав, ваш вчитель, мабуть, просто використовує ці приклади як привід, щоб змусити вас продовжувати заняття.