Почему подклассы не разрешены для многих элементов управления SWT?

Question

Я часто чувствую, что хочу это сделать.Это может быть очень полезно, когда вы хотите сохранить некоторую полезную информацию или дополнительные состояния.

Так что мой вопрос: есть ли очень веская / веская причина, почему это запрещено?

Спасибо

РЕДАКТИРОВАТЬ: Большое спасибо за все эти ответы.Похоже, нет правильного или неправильного ответа на этот вопрос.

Предполагая, что я принимаю тот факт, что эти классы не должны быть разделены на подклассы, какой смысл в , а не маркировке класса Controlокончательный, но запрещающий создание подклассов - эффективно переводить исключение / ошибку из времени компиляции во время выполнения?

РЕДАКТИРОВАТЬ ^ 2: См. мой собственный ответ на этот вопрос: очевидно, эти классы могут быть переопределены, но требуют явного подтвержденияoverrider.

Спасибо

Answer 1

Похоже, никто не упомянул об этом ни в одном из ответов, но SWT предоставляет переопределяемый метод checkSubclass();именно там, где выбрасывается неоправданное исключение.Переопределите метод для запрета и сделайте расширение легальным.Я полагаю, что оставить эту опцию открытой можно, в конечном счете, по причине того, что класс не сделан окончательным и ошибка расширения не была выполнена во время компиляции вместо времени выполнения.

Пример:

@Override
protected void checkSubclass() {
    //  allow subclass
    System.out.println("info   : checking menu subclass");
}

Answer 2

Разработка компонентов для наследования сложна и может ограничить будущие изменения реализации (конечно, если вы оставите некоторые методы переопределенными и вызовите их из других методов). Запрет на создание подклассов ограничивает пользователей, но означает, что легче написать надежный код.

Это следует за предложением Джоша Блоха "создать наследство или запретить его". Это немного религиозная тема в сообществе разработчиков - я согласен с мнением, но другие предпочитают, чтобы все было как можно более открытым.

Answer 3

Что касается вашего следующего вопроса:

какой смысл не отмечать Контрольный класс финальный, но запрещающий подклассы - эффективно понизить исключение / ошибка от времени компиляции до время выполнения?

SWT не может подкласс класса Control, если они помечают его как окончательный. Но они должны внутренне. Поэтому они откладывают проверку до времени выполнения.

Кстати, если вам нужен безумный взлом, вы все равно можете создать подкласс Control или любой другой класс SWT, поместив свой подкласс в пакет org.eclipse.swt.widgets. Но мне никогда не приходилось этого делать.

Answer 4

Очень трудно создать класс, который можно безопасно разделить на подклассы.Вы должны думать о бесконечных случаях использования и очень хорошо защищать свой класс.Я считаю, что это общая причина помечать класс API как окончательный.

Answer 5

Описание метода org.eclipse.swt.widgets.Widget.checkSubclass() гласит:

Проверяет, что этот класс может быть разделен на подклассы.

Библиотека классов SWT предназначена для подклассов только в определенных, контролируемые точки (прежде всего, Composite и Canvas, когда реализация новых виджетов). Этот метод применяет это правило, если оно не переопределяется.

ВАЖНО: Обеспечивая реализацию этого метода, который позволяет подкласс класса, который обычно не позволяет подклассам быть создан, исполнитель соглашается нести полную ответственность за факт что любой такой подкласс может потерпеть неудачу между выпусками SWT и будет быть сильно зависимым от платформы. Не предоставляется поддержка для написанного пользователем классы, которые реализованы таким образом.

Предусмотрена возможность создания подклассов вне разрешенных классов SWT исключительно для того, чтобы те, кто не входит в команду разработчиков SWT, могли реализовать патчи, чтобы обойти конкретные ограничения заранее, когда эти ограничения могут быть устранены командой. Подклассы не должны пытаться без глубокого и подробного понимания иерархия.

Броски: SWTException
ERROR_INVALID_SUBCLASS - если этот класс не является разрешенным подклассом