Patrón Abstract Factory - Interfaces Gráficas
|
|
Título del Test:
![]() Patrón Abstract Factory - Interfaces Gráficas Descripción: Test rápido para evaluar los componentes y la lógica del Patrón de Diseño Abstra |



| Comentarios |
|---|
NO HAY REGISTROS |
|
¿Cuál es el propósito principal del patrón Abstract Factory?. Asegurarse de que una clase tenga una única instancia en todo el programa (Singleton). Producir familias de objetos relacionados sin especificar sus clases concretas. Clonar objetos existentes para ahorrar memoria en lugar de crear nuevos desde cero. En nuestro ejemplo de interfaces gráficas, ¿qué rol cumple la interfaz GUIFactory?. Actúa como la Fábrica Abstracta que dicta qué elementos (botones y casillas) se deben crear. Es el Producto Concreto que se dibuja finalmente en la pantalla del usuario. Es la clase Cliente que toma la decisión final sobre en qué sistema operativo se está ejecutando la app. ¿Con qué componentes interactúa el código de nuestra clase Cliente (Aplicacion)?. Directamente con las clases concretas como BotonWindows o CasillaMac usando la palabra new. Exclusivamente con la base de datos para guardar el estado visual de los componentes. Únicamente con las interfaces abstractas, sin importarle el sistema operativo. Si a nuestra aplicación le pasamos la fábrica MacFactory, ¿qué componentes se crearán internamente?. Se instanciarán las clases concretas BotonMac y CasillaMac. Se instanciarán las interfaces abstractas Boton y Casilla. Se crearán todos los componentes de Windows, Mac y Linux al mismo tiempo por si el usuario cambia de opinión. ¿Qué problema grave evitamos al usar Abstract Factory en una app multiplataforma?. Evitamos que el código principal quede fuertemente "acoplado" (amarrado) a clases concretas usando directamente la palabra new. Evitamos que la aplicación consuma demasiada memoria RAM al cargar elementos gráficos pesados. Evitamos que los usuarios finales puedan tener acceso al código fuente de nuestra interfaz gráfica. |





