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

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

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

Спасибо

EDIT: Большое спасибо за все эти ответы. Похоже, что нет правильного или неправильного ответа на этот вопрос.

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

ИЗМЕНИТЬ ^ 2: См. Мой собственный ответ на этот вопрос: по-видимому, эти классы переопределяемы, но требуют явного подтверждения с помощью overrider.

Спасибо

Ответ 1

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

Пример:

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

Ответ 2

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

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

Ответ 3

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

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

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

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