Pátron Abstract Factory

¿Qué es el patrón Abstract Factory y en qué situaciones se recomienda su uso?. Un patrón de diseño estructural que facilita la creación de interfaces gráficas. Un patrón creacional que proporciona una interfaz para crear familias de objetos relacionados sin especificar sus clases concretas. Un patrón de diseño que se usa exclusivamente para la creación de bases de datos. Un patrón de comportamiento utilizado para gestionar eventos en una aplicación.

¿Cuál es la diferencia entre Abstract Factory y Factory Method?. Abstract Factory solo se usa con bases de datos, mientras que Factory Method se usa en cualquier contexto. Factory Method es un patrón estructural y Abstract Factory es un patrón de comportamiento. Abstract Factory proporciona una familia de objetos relacionados, mientras que Factory Method crea una única instancia de un producto. No hay diferencia, ambos patrones hacen exactamente lo mismo.

¿Cuáles son los principales componentes de una Abstract Factory?. Solo una clase base y clases concretas. Un controlador centralizado que gestiona la creación de todos los objetos del sistema. Una interfaz o clase abstracta que define la fábrica y múltiples fábricas concretas que implementan la interfaz. Un solo método estático que genera instancias de cualquier clase.

¿Cómo se implementa el patrón Abstract Factory en lenguajes como Java o C#?. Usando una clase estática con métodos que devuelvan objetos. Definiendo una interfaz para la fábrica y creando implementaciones concretas que generen productos específicos. Creando un constructor en cada clase para instanciar los objetos de la fábrica. No es posible implementarlo en estos lenguajes.

¿Qué ventaja ofrece Abstract Factory en el diseño de software?. Reduce el acoplamiento entre las clases concretas y permite crear familias de objetos de manera flexible. Hace que el código sea más complejo y difícil de mantener. No tiene ninguna ventaja significativa sobre instanciar objetos directamente. Solo es útil en proyectos pequeños y simples.

¿Cuál es una desventaja del patrón Abstract Factory?. Hace que la aplicación sea más lenta e ineficiente. Solo funciona con lenguajes de programación orientados a objetos. No permite la reutilización de código en ningún caso. Puede aumentar la complejidad del código debido a la creación de muchas clases y fábricas.

¿Cómo se puede extender una Abstract Factory para admitir nuevos productos sin modificar su código?. Modificando directamente todas las fábricas existentes. Usando la herencia y creando nuevas implementaciones de la fábrica. Eliminando la fábrica abstracta y creando instancias directamente en el código. No es posible extender una Abstract Factory sin modificar su código.

¿Cómo se relaciona Abstract Factory con el Principio de Inversión de Dependencias (DIP) en SOLID?. Abstract Factory viola el DIP porque introduce más clases en el sistema. Abstract Factory permite depender de abstracciones en lugar de implementaciones concretas, cumpliendo con el DIP. El DIP solo aplica a clases individuales y no a patrones de diseño. No hay ninguna relación entre Abstract Factory y el DIP.

¿Qué ocurre si se añaden nuevos productos a una familia en un patrón Abstract Factory?. Es necesario modificar todas las fábricas existentes para que puedan crear los nuevos productos. No es necesario modificar el código cliente, ya que la fábrica y los productos son extensibles sin modificar el código base. Los nuevos productos no pueden ser añadidos, ya que el patrón Abstract Factory solo soporta una cantidad fija de productos. El código cliente necesita ser modificado para manejar los nuevos productos directamente.

¿Qué beneficios tiene usar Abstract Factory en un sistema con múltiples plataformas o configuraciones?. Requiere que el código cliente conozca las implementaciones concretas para cada plataforma. Hace que el sistema sea más lento debido a la necesidad de crear múltiples fábricas para cada plataforma. No ofrece beneficios en sistemas que solo utilizan una plataforma. Permite crear objetos dependientes del sistema operativo sin que el código cliente tenga que preocuparse por la implementación concreta de cada plataforma.