Что такого особенного в CardLayout против ручного добавления/удаления JPanels?

Question

Там много раз были на StackOverflow, где пользователь задает вопрос, как это ...

У меня есть главный JPanel, который содержит ребенок JPanel. Когда пользователь нажимает кнопку , ребенок JPanel должен измениться на другой JPanel. Как я могу это сделать .

Чаще всего пользователь действительно пытался реализовать эту проблему, но не может заставить ее работать.

Всякий раз, когда я отвечу на этот вопрос, я говорю им, чтобы сделать что-то вроде этого (положить просто) ...

JPanel myFrame = new JPanel(); 
myFrame.remove(oldPanel); 
myFrame.add(newPanel); 

Я вижу это как вполне законный ответ, и я лично использовал это во многих мои собственные проекты Java без проблем. Тем не менее, я всегда получаю downvotes для моего ответа, и все просто говорят: «Используйте CardLayout».

Итак, мой вопрос: почему все так очарованы CardLayout, до того момента, когда мой ответ заслуживает нисходящего хода? Почему я должен использовать CardLayout вместо добавления/удаления панелей, используя мой код выше?

В качестве дополнительного вопроса вы бы по-прежнему предлагали CardLayout для интерфейсов с динамическими JPanels. Например, большинство моих программ реализуют настраиваемую платформу плагинов, где может быть много сотен JPanels, но я загружаю и отображаю панели так, как они на самом деле требуются. Для нормального использования программы большинство панелей никогда не загружались или не требовались. Для этого типа сценария мой подход кодирования будет лучшим решением, так как я понимаю, что CardLayout потребует от меня фактически создать все JPanels, хотя большинство из них никогда не будет использоваться?

Answer 1

• С CardLayout, это легче иметь слабую связь (хотя и не невозможно с реестром самостоятельно)
• С CardLayout, то PreferredSize карточного держателя является самой большой картой он держит.
• CardLayout сложнее, и позволяет почти тривиальный непрерывный компонент заменять его методы next() и prev().
• Вы можете легко связать желаемый компонент с константой - не нужно создавать Map<String, Component> для этой цели, поскольку он уже существует для вас. Я редко использовал перечисления для этого.
• Не нужно забывать звонить repaint() и revalidate() при замене компонентов.
• Он построен и позволяет легко повторно использовать компоненты.

Я не могу объяснить причину понижающего голосования, хотя, если они не расстраиваться вы не говоря уже о необходимости помнить, чтобы позвонить repaint() и revalidate() при замене компонентов. Вы должны будете спросить нисходящего, если они достаточно храбры, чтобы ответить.

Answer 2

CardLayout был тщательно протестирован и проверен на работоспособность. Он правильно получает component-tree lock и выполняет компонент validation, чтобы гарантировать, что ничего не получится.Ваше решение, хотя оно может работать большую часть времени, не удастся при определенных обстоятельствах.

Это все, что нужно, чтобы изобретать колесо: почему вы хотите, чтобы такой проверенный временем класс уже был доступен?