Final: Patrones de Diseño Flashcards
Explique Extensión de Interface y Objeto
📘 Planteo del problema: Necesidad de añadir funcionalidades a objetos de forma dinámica y transparente.
🛠️ Propósito: Permitir agregar responsabilidades a los objetos.
💡 Solución: Utilizar la herencia o la composición para extender funcionalidades.
🚧 Consecuencias: Incrementa la flexibilidad y reutilización del código, pero puede complicar la estructura del sistema.
❓ ¿Cuándo usarlo?
Contexto y problemas presentes en el diseño / código: software con componentes cliente y servidores. Diferentes releases complican el mantenimiento de versiones del servidor que debe evolucionar
Explique Factory Method
📘 Planteo del problema: La creación de objetos está estrechamente ligada a una clase específica.
🛠️ Propósito: Definir una interfaz para crear un objeto, permitiendo que las subclases decidan qué clase instanciar.
💡 Solución: Crear un método en la clase base que devuelva el objeto deseado.
🚧 Consecuencias: Desacopla la creación del objeto de su uso, pero puede llevar a una proliferación de clases.
Explique Builder
📘 Planteo del problema: Complejidad al crear y configurar un objeto con muchos parámetros opcionales.
🛠️ Propósito: Separar la construcción de un objeto complejo de su representación.
💡 Solución: Utilizar una clase Builder con métodos que configuren el objeto paso a paso.
🚧 Consecuencias: Mejora la claridad y flexibilidad del código, pero puede aumentar la complejidad del diseño.
Explique Facade
📘 Planteo del problema: Facadees un patrón de diseño estructural que proporciona una interfaz simplificada a una biblioteca, un framework o cualquier otro grupo complejo declases.
🛠️ Propósito: Proveer una interfaz simplificada a un conjunto de interfaces en un subsistema.
💡 Solución: Crear una clase Facade que encapsule la complejidad y provea métodos simplificados.
🚧 Consecuencias: Reduce la complejidad y desacopla el subsistema del cliente, pero puede ocultar funcionalidades importantes.
Explique Proxy
📘 Planteo del problema: Proxyes un patrón de diseño estructural que te permite proporcionar un sustituto o marcador de posición para otro objeto. Un proxy controla el acceso al objeto original, permitiéndote hacer algo antes o después de que la solicitud llegue al objetooriginal.
🛠️ Propósito: Proveer un sustituto o marcador de posición para controlar el acceso a un objeto.
💡 Solución: Crear una clase Proxy que controle el acceso al objeto real.
🚧 Consecuencias: Puede agregar capas de control y seguridad, pero también introduce latencia adicional.
Explique Iterator
📘 Planteo del problema: Necesidad de acceder a los elementos de una colección sin exponer su representación interna.
🛠️ Propósito: Proveer una manera de acceder secuencialmente a los elementos de una colección.
💡 Solución: Utilizar una interfaz Iterador que defina los métodos necesarios para recorrer la colección.
🚧 Consecuencias: Simplifica el acceso a las colecciones y promueve la encapsulación, pero puede aumentar la complejidad de la implementación de la colección.
Explique Command
📘 Planteo del problema: Necesidad de parametrizar objetos con operaciones.
🛠️ Propósito: Encapsular una solicitud como un objeto, permitiendo parametrizar clientes con diferentes solicitudes.
💡 Solución: Definir una interfaz Command con un método execute, e implementar diferentes comandos.
🚧 Consecuencias: Mejora la flexibilidad y la reutilización del código, pero puede aumentar el número de clases en el sistema.
Explique Bridge
📘 Planteo del problema: Evitar una explosión combinatoria de clases debido a la herencia.
🛠️ Propósito: Desacoplar una abstracción de su implementación, permitiendo que ambas varíen independientemente.
💡 Solución: Crear una jerarquía de clases para la abstracción y otra para la implementación, y conectar ambas jerarquías mediante una referencia.
🚧 Consecuencias: Aumenta la flexibilidad y facilita la extensión de ambas jerarquías, pero puede complicar el diseño inicial.
Explique Strategy
📘 Planteo del problema: Necesidad de cambiar el comportamiento de un objeto en tiempo de ejecución.
🛠️ Propósito: Definir una familia de algoritmos, encapsular cada uno, y hacerlos intercambiables.
💡 Solución: Crear una interfaz Strategy y varias implementaciones de la misma.
🚧 Consecuencias: Facilita la adición de nuevos algoritmos y promueve el principio de abierto/cerrado, pero puede incrementar el número de objetos y clases.
Explique State
📘 Planteo del problema: Cambiar el comportamiento de un objeto basado en su estado interno.
🛠️ Propósito: Permitir que un objeto altere su comportamiento cuando su estado cambia.
💡 Solución: Definir una interfaz State y clases concretas para cada estado.
🚧 Consecuencias: Facilita la adición de nuevos estados y promueve la encapsulación, pero puede complicar la gestión del estado.
Explique Template Method
📘 Planteo del problema: Necesidad de definir el esqueleto de un algoritmo en una operación, dejando algunos pasos a las subclases. Se usa cuando existe un algoritmo predefinido con uno o más pasos indefinidos
🛠️ Propósito: Definir la estructura de un algoritmo en una operación, delegando algunos pasos a subclases.
💡 Solución: Crear un método en una clase abstracta que llame a otros métodos que pueden ser implementados por las subclases.
🚧 Consecuencias: Facilita la reutilización de código y promueve la consistencia, pero puede restringir la flexibilidad de las subclases.
Explique Composite
📘 Planteo del problema: Necesidad de tratar objetos individuales y composiciones de objetos de manera uniforme.
🛠️ Propósito: Componer objetos en estructuras de árbol para representar jerarquías parte-todo.
💡 Solución: Definir una interfaz común para objetos individuales y compuestos, y crear clases para cada uno.
🚧 Consecuencias: Facilita el manejo de estructuras complejas, pero puede complicar el diseño debido a la necesidad de gestionar las relaciones jerárquicas.
Explique Decorator
📘 Planteo del problema: Agregar responsabilidades a los objetos de manera flexible y dinámica.
🛠️ Propósito: Adjuntar responsabilidades adicionales a un objeto de manera dinámica.
💡 Solución: Crear una clase Decorator que implemente la misma interfaz que el objeto decorado y añada nuevas funcionalidades.
🚧 Consecuencias: Mejora la flexibilidad y la reutilización, pero puede aumentar la complejidad del diseño y la comprensión del código.
Explique Visitor
📘 Planteo del problema: Visitor es un patrón de diseño de comportamiento que te permite separar algoritmos de los objetos sobre los que operan.
🛠️ Propósito: Representar una operación a realizar en los elementos de una estructura de objetos.
💡 Solución: Definir una interfaz Visitor con métodos para cada tipo de elemento, y hacer que los elementos acepten un visitor.
🚧 Consecuencias: Facilita la adición de nuevas operaciones sin modificar los objetos, pero puede romper el encapsulamiento y aumentar la complejidad.
Explique Adapter
📘 Planteo del problema: Adapteres un patrón de diseño estructural que permite la colaboración entre objetos con interfaces incompatibles. Se trata de un objeto especial que convierte la interfaz de un objeto, de forma que otro objeto pueda comprenderla.
🛠️ Propósito: Permitir que clases con interfaces incompatibles trabajen juntas.
💡 Solución: Crear una clase Adapter que implemente la interfaz deseada y delegue las llamadas a un objeto de la clase adaptada.
🚧 Consecuencias: Facilita la reutilización de clases existentes, pero puede agregar complejidad debido a la necesidad de traducir interfaces.
