Итак, мой вопрос, почему они так делают
Есть две "основные" причины, почему.Во-первых, это общее хорошее программирование.
Мы рекомендуем избегать расширения классов, в которые мы не добавляем никаких новых или повторяемых функций.Если вся причина расширения от JFrame
заключается просто в том, что вы можете отобразить некоторые компоненты, тогда это действительно плохой выбор или отправная точка.
JFrame
также является сложным, составным компонентом.То есть фактически он состоит из ряда других многоуровневых компонентов, которые работают вместе для обеспечения общего опыта.
* От КакИспользование корневых панелей
Это означает, что есть много дополнительных сложностей, которыми вы должны были бы управлять, если вы выходите из этого класса, много накладных расходов только для отображения нескольких компонентов.
В принципе, лучше использовать композицию, а не наследование, что приводит ко второму пункту.
Расширение из любого класса блокирует вас в этом сценарии использования.В случае JFrame
вы можете только когда-либо отображать то, что когда-либо управляется классом через JFrame
, нет гибкости или точки входа для повторного использования.
Если вместо этого вы началис базовым классом, скажем, JPanel
, вы можете добавить, что к любому контейнеру, который вы хотите, когда хотите, это увеличивает гибкость и возможность повторного использования класса для всех.
ДляПример моего вопроса (я не знаю, настоящий он или нет) в классе JFrame: кнопка закрытия всегда идет вправо к углу окна, но если я делаю это по-другому, вы можете поместить ее везде, где захотите.можно ответить да или нет)
Да и нет.Граница фрейма определяется внешним видом и ощущением делегата, так что вы на самом деле начинаете не с того места, с которого нужно начинать.
Большинство делегатов, использующих внешний вид, делегируют границу фрейма на собственную платформу, в случае Windows да, кнопка закрытия находится справа, на Mac - слева.
Inв любом случае, лучше поддерживать ожидания пользователей, размещение кнопки закрытия в необычном месте может сделать пользовательский интерфейс «красивым», но снижает удобство работы с пользователем - в качестве общего руководства не уменьшайте пользовательский опыт, каким бы удивительным он ни был.ваша программа или пользовательский интерфейс, вам не понравится пользователь, но это (очень широкий) вопрос на следующий день