layouts - layout manager java

¿Qué tiene de especial CardLayout frente a la adición/eliminación manual de JPanels?

Question

Ha habido muchas veces en StackOverflow donde un usuario hace una pregunta como esta ...

Tengo un JPanel principal que contiene un JPanel hijo. Cuando el usuario hace clic en un botón, el niño JPanel debe cambiar a un JPanel diferente. Cómo puedo conseguir esto.

La mayoría de las veces, el usuario ha intentado implementar este problema, pero no puede hacerlo funcionar.

Cada vez que respondo esta pregunta, les digo que hagan algo como esto (en pocas palabras) ...

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

Veo esto como una respuesta bastante legítima, y ​​personalmente he usado esto en muchos de mis propios proyectos Java sin problemas. Sin embargo, siempre recibo votos atrasados ​​por mi respuesta, y todos dicen "Use CardLayout ".

Entonces mi pregunta es, ¿por qué todos están tan fascinados con CardLayout , hasta el punto en que mi respuesta merece un voto negativo? ¿Por qué debería elegir usar un CardLayout lugar de agregar / eliminar paneles usando mi código anterior?

Como una pregunta adicional, ¿todavía estaría sugiriendo CardLayout para interfaces que tienen paneles dinámicos de JP? Por ejemplo, la mayoría de mis programas implementan un marco de plugin personalizado donde podría haber cientos de JPanels , pero solo cargo y muestra los paneles como realmente se requieren. Para el uso normal del programa, la mayoría de los paneles nunca serían cargados o requeridos. Para este tipo de escenario, ¿mi enfoque de codificación sería la mejor solución, ya que entiendo que CardLayout requeriría que realmente crease todos los JPanels , aunque la mayoría nunca se utilizarán?

Answer 1

CardLayout ha sido completamente probado y probado para funcionar. Adquiere correctamente el bloqueo de árbol de componentes y realiza la validación de componentes para garantizar que nada salga mal. Su solución, aunque puede funcionar la mayor parte del tiempo, fallará en ciertas circunstancias.

Todo esto se reduce a reinventar la rueda: ¿por qué querrías cuando ya está disponible una clase con la prueba del tiempo?

Answer 2

• Con CardLayout, es más fácil tener un acoplamiento flojo (aunque no imposible con el propio)
• Con CardLayout, el tamaño preferido del titular de la tarjeta es el de la tarjeta más grande que posee.
• CardLayout es más difícil de usar y permite que un componente contiguo casi trivial intercambie sus métodos next() y prev() .
• Puede asociar fácilmente el componente deseado con una constante; no es necesario crear un Map<String, Component> para este fin, ya que está disponible para usted. No pocas veces he usado enumeraciones para esto.
• No es necesario recordar llamar a repaint() y revalidate() al intercambiar componentes.
• Está diseñado y permite una fácil reutilización de componentes.

Sin embargo, no puedo explicar el motivo de un voto negativo, a menos que estén molestos, no mencionaron la necesidad de recordar llamar a repaint() y revalidate() al intercambiar componentes. Tendrá que preguntarle al votante de abajo si es lo suficientemente valiente como para responder.