test-01

¿Cuál es el PROPÓSITO de Factory Method?

• Proporcionar una interfaz para crear objetos en una superclase, permitiendo que subclases alteren el tipo de objetos a crear.
• Agrupar objetos relacionados en jerarquías parte‑todo tratándolos de forma uniforme.
• Permitir notificar a múltiples interesados cuando un sujeto cambie de estado.
• Compartir estado común para manejar eficientemente gran cantidad de objetos.
• Separar operaciones de las estructuras de datos para agregarlas sin modificar clases.

¿Qué SITUACIÓN-PROBLEMA describe mejor la necesidad de usar Factory Method?

• Delegar la creación de objetos sin acoplar el cliente a clases concretas, permitiendo variar productos sin modificar el código cliente.
• Necesidad de crear familias de productos compatibles y sustituibles en conjunto.
• Inicializar objetos con muchos parámetros opcionales y combinaciones, evitando constructores telescópicos.
• Crear muchas instancias similares o costosas de inicializar de forma eficiente.
• Controlar el acceso a un recurso compartido evitando instancias duplicadas y variables globales.

Seleccione las VENTAJAS reales de Factory Method.

• Evitas un acoplamiento fuerte entre el creador y los productos concretos.
• Principio de responsabilidad única. Puedes mover el código de creación de producto a un lugar del programa, haciendo que el código sea más fácil de mantener.
• Principio de abierto/cerrado. Puedes incorporar nuevos tipos de productos en el programa sin descomponer el código cliente existente.
• Aumenta el acoplamiento fuerte entre componentes.
• Garantiza thread‑safety por defecto en todos los entornos.

Seleccione las DESVENTAJAS de Factory Method.

• Puede ser que el código se complique, ya que debes incorporar una multitud de nuevas subclases para implementar el patrón. La situación ideal sería introducir el patrón en una jerarquía existente de clases creadoras.
• Reduce la cantidad de clases y simplifica la jerarquía.
• Facilita el mantenimiento centralizando toda la lógica.
• Permite introducir nuevas variantes sin cambiar el cliente.
• Promueve el principio de abierto/cerrado de forma automática.

¿Cuál es el PROPÓSITO de Abstract Factory?

• Producir familias de objetos relacionados sin especificar sus clases concretas.
• Agrupar objetos relacionados en jerarquías parte‑todo tratándolos de forma uniforme.
• Permitir notificar a múltiples interesados cuando un sujeto cambie de estado.
• Compartir estado común para manejar eficientemente gran cantidad de objetos.
• Separar operaciones de las estructuras de datos para agregarlas sin modificar clases.

¿Qué SITUACIÓN-PROBLEMA describe mejor la necesidad de usar Abstract Factory?

• Necesidad de crear familias de productos compatibles y sustituibles en conjunto.
• Delegar la creación de objetos sin acoplar el cliente a clases concretas, permitiendo variar productos sin modificar el código cliente.
• Inicializar objetos con muchos parámetros opcionales y combinaciones, evitando constructores telescópicos.
• Crear muchas instancias similares o costosas de inicializar de forma eficiente.
• Controlar el acceso a un recurso compartido evitando instancias duplicadas y variables globales.

Seleccione las VENTAJAS reales de Abstract Factory.

• Puedes tener la certeza de que los productos que obtienes de una fábrica son compatibles entre sí.
• Evitas un acoplamiento fuerte entre productos concretos y el código cliente.
• Principio de responsabilidad única. Puedes mover el código de creación de productos a un solo lugar, haciendo que el código sea más fácil de mantener.
• Principio de abierto/cerrado. Puedes introducir nuevas variantes de productos sin descomponer el código cliente existente.
• Aumenta el acoplamiento fuerte entre componentes.

Seleccione las DESVENTAJAS de Abstract Factory.

• Puede ser que el código se complique más de lo que debería, ya que se introducen muchas nuevas interfaces y clases junto al patrón.
• Reduce la cantidad de clases y simplifica la jerarquía.
• Facilita el mantenimiento centralizando toda la lógica.
• Permite introducir nuevas variantes sin cambiar el cliente.
• Promueve el principio de abierto/cerrado de forma automática.

¿Cuál es el PROPÓSITO de Builder?

• Construir objetos complejos paso a paso; el mismo proceso puede crear distintas representaciones.
• Agrupar objetos relacionados en jerarquías parte‑todo tratándolos de forma uniforme.
• Permitir notificar a múltiples interesados cuando un sujeto cambie de estado.
• Compartir estado común para manejar eficientemente gran cantidad de objetos.
• Separar operaciones de las estructuras de datos para agregarlas sin modificar clases.

¿Qué SITUACIÓN-PROBLEMA describe mejor la necesidad de usar Builder?

• Inicializar objetos con muchos parámetros opcionales y combinaciones, evitando constructores telescópicos.
• Delegar la creación de objetos sin acoplar el cliente a clases concretas, permitiendo variar productos sin modificar el código cliente.
• Necesidad de crear familias de productos compatibles y sustituibles en conjunto.
• Crear muchas instancias similares o costosas de inicializar de forma eficiente.
• Controlar el acceso a un recurso compartido evitando instancias duplicadas y variables globales.