Mal uso de patrones de diseño en el marco Swing
El control Swing es un control GUI liviano desarrollado para mejorar el control AWT. Adopta el patrón de diseño compuesto. Sin embargo, el control Swing se debe a la falta de un límite claro que separe el componente y el contenedor. Casi todos los componentes son contenedores que pueden agregar otros contenedores o componentes. Las funciones aparentemente poderosas en realidad causan muchos problemas.
Los diversos componentes de la GUI de Swing son muy inconsistentes con la intuición humana. Cuando se agregan, las capas de cada componente serán muy profundas. Será muy problemático lidiar con problemas como la gestión del enfoque y la conversión de coordenadas también es muy complicada. Dado que hay demasiadas relaciones entre padres e hijos, no es necesario. mire el código y solo mire la GUI. Es difícil distinguir intuitivamente el componente principal y el secundario. Relación
Problemas al usar el componente Swing en sí, ya que no está claro si es un componente. o un contenedor, muchos métodos de contenedor como setEnabled no tienen ningún efecto. Debe escribir código para atravesar todos los subcomponentes y llamar al mismo método en todos los subcomponentes, que es similar a configurar la transparencia. Si configura un contenedor para que sea transparente, también debe configurar las propiedades transparentes de todos los subcomponentes. Muchos métodos de componentes y contenedores no están bien definidos. Esto no es un problema para las personas que comprenden la estructura Swing, pero no lo es. un problema para las personas que están familiarizadas con otras bibliotecas de clases GUI. Esto causó mucha confusión porque muchos métodos en el contenedor no tuvieron efecto después de ser llamados
Dificultades en el diseño que encontrarán los programadores que usan Swing para desarrollar interfaces. Aunque Swing proporciona tantos administradores de diseño, desea crear una interfaz muy profesional a través de estos administradores de diseño, pero es muy difícil porque el administrador de diseño depende en gran medida de los distintos estados del contenedor principal y de los componentes secundarios, aunque es la última versión. Swing proporciona métodos similares para el espaciado de componentes y contenedores, pero la mayoría no los ha utilizado. La adopción de administradores de diseño no es en realidad un problema de que los administradores de diseño no sean lo suficientemente potentes. De hecho, muchas interfaces profesionales deben estar bien definidas desde el componente. Por ejemplo, los métodos getPreferredSize, getMinimumSize y getMaximumSize son muy inciertos. Los administradores de diseño no pueden confiar demasiado en estos métodos. Además, muchos componentes Swing se dibujan de acuerdo con el tamaño del contenedor. A muchas personas les gusta usar NullLayout. Esta puede ser la razón por la que los clientes necesitan una interfaz estable y predecible. Si usa un administrador de diseño, encontrará que la interfaz es diferente en diferentes sistemas.
Comparando muchos. Bibliotecas de clases GUI, encontrará que sus definiciones son más estrictas. Por ejemplo, los componentes y contenedores de la biblioteca de clases LCDUI de JavaME están estrictamente separados. La adición de componentes también está estrictamente definida y no tiene un diseño. El administrador de diseño admite soportes como las barras de desplazamiento en la capa inferior, lo que realmente reduce la carga para los desarrolladores de GUI
lishixinzhi/Article/program/Java/hx/201311/26380
.