🧩 Diseño de módulos, componentes y de datos

1. ¿Qué principio de diseño orientado a objetos establece que una clase debe tener una sola razón para cambiar?

1. Principio Abierto/Cerrado (OCP)
2. Principio de Responsabilidad Única (SRP)
3. Principio de Sustitución de Liskov (LSP)
4. Principio de Inversión de Dependencias (DIP)

El SRP indica que una clase debe tener una única responsabilidad y, por tanto, una sola razón para cambiar; los demás principios regulan extensión, sustitución de subtipos o dependencia de abstracciones, no el número de responsabilidades. (Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices, cap. 8.)

2. Un desarrollador tiene una clase ReporteVentas que calcula totales de ventas, genera el formato del documento en PDF y además guarda el archivo en una carpeta del servidor. Al modificar el formato de impresión, también se rompe la lógica de cálculo. ¿Qué principio SOLID se está violando?

1. Principio de Responsabilidad Única (SRP)
2. Principio Abierto/Cerrado (OCP)
3. Principio de Segregación de Interfaces (ISP)
4. Principio de Inversión de Dependencias (DIP)

La clase mezcla tres responsabilidades (cálculo, formato y almacenamiento), por lo que cualquier cambio en una afecta a las otras, lo cual es la violación clásica del SRP. (Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices, cap. 8.)

3. ¿Qué establece el Principio Abierto/Cerrado (OCP) respecto de las entidades de software (clases, módulos, funciones)?

1. Deben depender únicamente de clases concretas y no de abstracciones
2. Deben permitir que cualquier subclase reemplace a la clase base sin cambios
3. Deben estar abiertas para su extensión pero cerradas para su modificación
4. Deben exponer todos sus métodos a través de una sola interfaz general

El OCP, formulado por Meyer y reformulado por Martin, exige que el comportamiento se pueda extender sin alterar el código ya probado; la opción sobre subclases corresponde al LSP, no al OCP. (Meyer, B. (1988). Object-Oriented Software Construction; Martin, R. C. (2002).)

4. Un sistema de cálculo de descuentos usa una instrucción switch que evalúa el tipo de cliente (regular, mayorista, gobierno) para aplicar la fórmula correspondiente. Cada vez que se agrega un nuevo tipo de cliente, se debe modificar esa instrucción en varios archivos. ¿Qué solución de diseño resuelve mejor esta violación del OCP?

1. Aumentar el número de parámetros del método para cubrir todos los casos futuros
2. Definir una interfaz de estrategia de descuento e implementar una clase por cada tipo de cliente
3. Documentar el código con comentarios que expliquen cada caso del switch
4. Convertir el método en privado para restringir su acceso desde otras clases

Extraer una interfaz de estrategia (patrón Strategy) permite agregar nuevos tipos de cliente creando clases nuevas sin modificar el código existente, cumpliendo el OCP. (Meyer, B. (1988). Object-Oriented Software Construction; Martin, R. C. (2002).)

5. Una clase Rectangulo tiene los métodos fijarAncho y fijarAlto, cada uno independiente. La clase Cuadrado hereda de Rectangulo y sobrescribe ambos métodos para que, al fijar un valor, se actualicen ancho y alto por igual. Un programa que usa Rectangulo y espera que el área cambie solo en la dimensión modificada falla al recibir un objeto Cuadrado. ¿Qué principio SOLID se viola?

1. Principio de Sustitución de Liskov (LSP)
2. Principio de Responsabilidad Única (SRP)
3. Principio de Segregación de Interfaces (ISP)
4. Principio Abierto/Cerrado (OCP)

El ejemplo es el caso clásico del LSP: Cuadrado no puede sustituir a Rectangulo sin alterar el comportamiento esperado por el cliente, lo que rompe la sustituibilidad exigida por Liskov. (Liskov, B. (1987). Data Abstraction and Hierarchy, OOPSLA keynote.)

6. Según el Principio de Inversión de Dependencias (DIP), ¿cómo deben relacionarse los módulos de alto nivel y los de bajo nivel en un sistema?

1. Los módulos de bajo nivel deben depender de los módulos de alto nivel
2. Los módulos de alto nivel deben depender directamente de las clases concretas de bajo nivel
3. Los módulos de alto nivel deben conocer los detalles de implementación de los de bajo nivel
4. Ambos deben depender de abstracciones, no uno del otro directamente

El DIP establece que tanto los módulos de alto como de bajo nivel deben depender de abstracciones (interfaces), invirtiendo la dependencia tradicional del nivel alto hacia el bajo. (Martin, R. C. (1996). The Dependency Inversion Principle, C++ Report.)

7. Una clase ProcesadorPedidos crea internamente una instancia concreta de BaseDatosMySQL para guardar los pedidos. Si la empresa decide migrar a otro motor de base de datos, hay que modificar ProcesadorPedidos. ¿Qué cambio de diseño aplica el DIP para resolver este problema?

1. Agregar más métodos a la clase BaseDatosMySQL para cubrir nuevos requerimientos
2. Hacer que ProcesadorPedidos reciba una interfaz RepositorioPedidos en su constructor
3. Declarar la clase ProcesadorPedidos como clase final para evitar su modificación
4. Duplicar la clase ProcesadorPedidos y adaptar una copia a cada motor de base de datos

Inyectar una abstracción (RepositorioPedidos) en lugar de instanciar una clase concreta permite cambiar el motor de base de datos sin modificar ProcesadorPedidos, que es la esencia del DIP. (Martin, R. C. (1996). The Dependency Inversion Principle, C++ Report.)

8. ¿Qué establece el Principio de Segregación de Interfaces (ISP)?

1. Ningún cliente debe ser forzado a depender de métodos que no utiliza
2. Toda clase debe implementar una única interfaz general para todos sus clientes
3. Las interfaces deben contener la mayor cantidad posible de métodos
4. Un cliente debe depender de tantas interfaces concretas como sea posible

El ISP propone dividir interfaces grandes en interfaces más pequeñas y específicas, de modo que cada cliente solo dependa de los métodos que realmente usa. (Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices, cap. 12.)

9. Una interfaz Trabajador define los métodos trabajar y comer. Una clase RobotSoldador implementa Trabajador pero el método comer no tiene sentido para ella, por lo que se implementa lanzando una excepción. ¿Qué solución de diseño corrige esta violación del ISP?

1. Eliminar el método comer de todas las clases que implementan Trabajador
2. Convertir comer en un método estático para que no dependa de la instancia
3. Hacer que RobotSoldador herede también de una clase Humano
4. Separar Trabajador en dos interfaces más pequeñas, como Laborable y Alimentable

Segregar la interfaz en dos más específicas evita que RobotSoldador se vea obligado a implementar un método que no le corresponde, resolviendo el problema conforme al ISP. (Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices, cap. 12.)

10. ¿Cuántos principios de diseño orientado a objetos agrupa el acrónimo SOLID?

1. Cuatro
2. Cinco
3. Siete
4. Nueve

SOLID agrupa cinco principios: SRP, OCP, LSP, ISP y DIP, popularizados por Michael Feathers y Robert C. Martin. (Martin, R. C. (2000). Design Principles and Design Patterns.)

11. ¿Cuál de los siguientes NO es uno de los cinco principios agrupados en el acrónimo SOLID?

1. Principio de Responsabilidad Única (SRP)
2. Principio de Sustitución de Liskov (LSP)
3. Principio de No Repetición (DRY)
4. Principio de Inversión de Dependencias (DIP)

DRY (Don't Repeat Yourself) es un principio de diseño distinto, propuesto por Hunt y Thomas, y no forma parte del acrónimo SOLID, el cual incluye SRP, OCP, LSP, ISP y DIP. (Martin, R. C. (2000); Hunt, A., Thomas, D. (1999). The Pragmatic Programmer.)

12. Un equipo de diseño discute la diferencia entre el Principio Abierto/Cerrado y el Principio de Sustitución de Liskov. ¿Cuál es la distinción correcta entre ambos?

1. El OCP exige que las subclases sustituyan a la clase base; el LSP exige cerrar las clases para evitar su modificación
2. El OCP y el LSP son principios sinónimos que exigen exactamente la misma condición de diseño orientado a objetos
3. El OCP se aplica únicamente a bases de datos; el LSP se aplica únicamente a interfaces gráficas de usuario
4. El OCP exige extender comportamiento sin modificar código existente; el LSP exige que las subclases sustituyan a la clase base sin errores

El OCP trata sobre extensibilidad sin modificar código probado, y el LSP trata sobre la correcta sustituibilidad de subtipos; son complementarios pero distintos, como los definieron Meyer y Liskov respectivamente. (Meyer, B. (1988); Liskov, B. (1987). OOPSLA keynote.)

13. Según la clasificación del Gang of Four (GoF), ¿cuántos patrones estructurales existen en su catálogo original?

1. Cinco
2. Nueve
3. Once
4. Siete

El catálogo del GoF define siete patrones estructurales: Adapter, Bridge, Composite, Decorator, Facade, Flyweight y Proxy. (Gamma et al. (1994). Design Patterns, cap. 4 (Structural Patterns).)

14. ¿Cuál es el propósito principal del patrón Adapter en el catálogo del GoF?

1. Componer objetos en estructuras de árbol para representar jerarquías parte-todo
2. Convertir la interfaz de una clase en otra interfaz que el cliente espera
3. Añadir responsabilidades adicionales a un objeto de manera dinámica
4. Proporcionar un sustituto o representante de otro objeto para controlar el acceso a él

El Adapter permite que clases con interfaces incompatibles trabajen juntas al traducir la interfaz de una clase a la que el cliente necesita; las demás descripciones corresponden a Composite, Decorator y Proxy respectivamente. (Gamma et al. (1994). Design Patterns, cap. 4 (Adapter).)

15. Una empresa integra una librería de pagos de un proveedor externo cuya clase expone el método procesarCobro(monto, moneda), pero el sistema interno de la empresa espera una interfaz con el método pagar(orden). ¿Qué patrón de diseño resuelve esta incompatibilidad sin modificar el código del proveedor externo?

1. Decorator
2. Composite
3. Adapter
4. Singleton

El Adapter envuelve la clase del proveedor externo y traduce las llamadas pagar(orden) hacia procesarCobro(monto, moneda), integrando interfaces incompatibles sin alterar el código original. (Gamma et al. (1994). Design Patterns, cap. 4 (Adapter).)

16. ¿Qué característica define al patrón Decorator dentro de los patrones estructurales del GoF?

1. Convierte la interfaz de una clase en la interfaz que espera el cliente
2. Reduce el número de instancias compartiendo objetos similares en memoria
3. Agrega responsabilidades a un objeto de manera dinámica sin alterar su clase
4. Define una jerarquía de clases abstractas para separar una abstracción de su implementación

El Decorator envuelve un objeto para añadirle funcionalidad adicional en tiempo de ejecución, como alternativa flexible a la herencia; las otras opciones describen Adapter, Flyweight y Bridge. (Gamma et al. (1994). Design Patterns, cap. 4 (Decorator).)

17. En un sistema de manejo de archivos de texto, se requiere poder combinar de forma dinámica funciones como compresión, cifrado y registro de auditoría sobre un flujo de datos base, sin crear una subclase por cada combinación posible. ¿Qué patrón de diseño es más adecuado para este requerimiento?

1. Decorator
2. Adapter
3. Facade
4. Composite

El Decorator permite envolver el flujo base con varias capas de comportamiento (compresión, cifrado, auditoría) que se pueden combinar dinámicamente, evitando la explosión de subclases que produciría la herencia. (Gamma et al. (1994). Design Patterns, cap. 4 (Decorator).)

18. ¿Qué problema resuelve el patrón Composite en el diseño orientado a objetos?

1. Permite que dos interfaces incompatibles se comuniquen entre sí
2. Permite agregar comportamiento a un objeto sin modificar su clase
3. Permite limitar el número de instancias de una clase a una sola
4. Permite tratar de forma uniforme objetos individuales y sus composiciones en árbol

El Composite organiza objetos en estructuras de árbol parte-todo y permite que el cliente trate a los elementos simples y a las composiciones con la misma interfaz. (Gamma et al. (1994). Design Patterns, cap. 4 (Composite).)

19. Un sistema de administración de archivos debe calcular el tamaño total de una carpeta que puede contener tanto archivos individuales como otras carpetas anidadas, tratando ambos casos con el mismo método obtenerTamano(). ¿Qué patrón de diseño estructural corresponde a este caso?

1. Bridge
2. Composite
3. Proxy
4. Decorator

El Composite modela jerarquías parte-todo (carpetas y archivos) permitiendo invocar el mismo método sobre elementos simples y compuestos, tal como se requiere en este caso. (Gamma et al. (1994). Design Patterns, cap. 4 (Composite).)

20. ¿Cuál es la diferencia esencial entre el patrón Adapter y el patrón Decorator?

1. El Adapter añade responsabilidades a un objeto; el Decorator traduce una interfaz incompatible en otra distinta
2. El Adapter se aplica solo a bases de datos; el Decorator se aplica solo a interfaces gráficas de usuario
3. El Adapter cambia la interfaz de un objeto para que sea compatible con la esperada; el Decorator conserva la interfaz y añade responsabilidades
4. El Adapter y el Decorator cumplen la misma función y se usan como sinónimos en el catálogo del GoF

El Adapter existe para resolver incompatibilidad de interfaces, mientras que el Decorator preserva la interfaz original del componente y únicamente le añade comportamiento adicional en tiempo de ejecución. (Gamma et al. (1994). Design Patterns, cap. 4.)

21. Un diseñador debe elegir entre Decorator y Composite para modelar un componente gráfico. ¿Qué criterio distingue correctamente cuándo usar cada uno?

1. Ambos patrones son intercambiables porque comparten la misma estructura de clases y el mismo propósito
2. Composite modela jerarquías parte-todo tratadas uniformemente; Decorator añade responsabilidades a un objeto sin crear subclases
3. Composite se aplica solo a colecciones numéricas; Decorator se aplica solo a cadenas de texto
4. Composite se usa para traducir interfaces incompatibles; Decorator se usa para representar jerarquías parte-todo

Aunque ambos usan composición de objetos con una interfaz común, Composite modela jerarquías parte-todo, mientras que Decorator añade capas de comportamiento a un único componente sin representar una jerarquía estructural. (Gamma et al. (1994). Design Patterns, cap. 4.)

22. ¿Cuál de los siguientes patrones NO pertenece a la categoría de patrones estructurales del catálogo GoF?

1. Facade
2. Bridge
3. Observer
4. Flyweight

Observer es un patrón de comportamiento, mientras que Facade, Bridge y Flyweight sí pertenecen a los siete patrones estructurales definidos por el GoF. (Gamma et al. (1994). Design Patterns, cap. 4 y cap. 5.)

23. En el diseño de componentes reutilizables, ¿qué combinación de características internas y externas se busca maximizar y minimizar, respectivamente, para facilitar su reutilización?

1. Maximizar el acoplamiento entre módulos y minimizar la cohesión interna
2. Maximizar el número de métodos públicos y minimizar el número de clases
3. Maximizar la cohesión interna y minimizar el acoplamiento entre módulos
4. Maximizar la herencia múltiple y minimizar el uso de interfaces

Un componente reutilizable debe tener alta cohesión (unidad funcional interna) y bajo acoplamiento (poca dependencia de otros módulos), lo que facilita su reutilización en distintos contextos. (Stevens, W., Myers, G., Constantine, L. (1974). Structured Design, IBM Systems Journal.)

24. Un componente ValidadorCorreo depende directamente de una clase concreta ConexionServidorSMTP para validar la existencia del dominio, lo que impide reutilizar el componente en proyectos sin ese servidor. ¿Qué acción de diseño mejora la reutilización de este componente?

1. Copiar el código de ValidadorCorreo en cada proyecto que lo requiera
2. Incluir la conexión al servidor SMTP como un atributo estático de la clase
3. Aumentar el número de parámetros del método de validación para cubrir más casos
4. Definir una interfaz de validación e inyectar la implementación desde fuera del componente

Separar el componente de la implementación concreta mediante una interfaz y aplicar inyección de dependencias reduce el acoplamiento y permite reutilizar ValidadorCorreo en distintos contextos, incluso sin servidor SMTP. (Stevens, W., Myers, G., Constantine, L. (1974); Martin, R. C. (1996). DIP.)

25. ¿Qué establece el principio DRY (Don't Repeat Yourself) aplicado al diseño de componentes de software?

1. Cada componente debe duplicar la lógica de validación para mayor seguridad
2. Cada pieza de conocimiento del sistema debe tener una representación única y autoritativa
3. Cada módulo debe implementar su propia versión de las funciones comunes del sistema
4. Cada clase debe repetir la definición de sus atributos en todas las subclases

El DRY, propuesto por Hunt y Thomas, busca evitar la duplicación de conocimiento o lógica en el sistema, concentrándola en una sola representación reutilizable. (Hunt, A., Thomas, D. (1999). The Pragmatic Programmer.)

26. Un equipo diseña un componente CalculadoraImpuestos que debe usarse en varios sistemas de facturación de distintas empresas, cada una con reglas fiscales diferentes. El componente actualmente contiene las reglas de una sola empresa integradas en su código. ¿Qué estrategia de diseño aumenta mejor su reutilización sin generar una copia por cada empresa?

1. Fijar las reglas fiscales de la empresa más grande como valor predeterminado del componente
2. Aumentar la cantidad de condicionales internos para cubrir cada empresa dentro de la misma clase
3. Extraer las reglas fiscales a una interfaz de estrategia que el componente reciba como parámetro externo
4. Compilar una versión distinta del componente para cada empresa que lo utilice

Externalizar las reglas variables mediante una interfaz de estrategia (similar al patrón Strategy) desacopla el componente de una regla fiscal específica, permitiendo su reutilización en múltiples contextos sin duplicar código. (Stevens, W., Myers, G., Constantine, L. (1974); Meyer, B. (1988). OCP aplicado a componentes.)

27. Al diseñar un componente que debe integrarse en múltiples aplicaciones cliente sin conocer sus detalles internos, ¿cuál es la práctica de diseño más recomendada para exponer su funcionalidad?

1. Exponer todos los atributos internos del componente como públicos para mayor flexibilidad
2. Permitir que cada aplicación cliente acceda directamente a las clases concretas internas del componente
3. Evitar el uso de interfaces y depender únicamente de la herencia entre clases concretas
4. Exponer una interfaz pública bien definida y ocultar los detalles de implementación mediante encapsulamiento

Exponer una interfaz pública clara y encapsular la implementación permite que los clientes usen el componente sin acoplarse a sus detalles internos, facilitando su reutilización y mantenimiento. (Booch, G. (1994). Object-Oriented Analysis and Design with Applications, 2a ed.; Stevens et al. (1974).)

28. En el patrón GRASP conocido como Experto en Información, ¿a qué clase se le debe asignar una responsabilidad?

1. A la clase con menor número de atributos del modelo
2. A la clase que actúa como controlador de la interfaz de usuario
3. A la clase que posee la información necesaria para cumplir esa responsabilidad
4. A la clase que tiene mayor acoplamiento con las demás clases del sistema

El patrón Experto asigna la responsabilidad a la clase que posee la información necesaria para cumplirla, lo que además ayuda a mantener bajo acoplamiento. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Information Expert).)

29. En un sistema de ventas, la clase Pedido contiene una colección de objetos LineaPedido, y cada LineaPedido conoce su cantidad y el precio unitario del producto. Según el patrón Experto en Información, ¿qué clase debe calcular el subtotal de una línea de pedido?

1. LineaPedido, porque conoce la cantidad y el precio necesarios
2. Pedido, porque agrupa todas las líneas del pedido
3. Producto, porque define el precio unitario
4. Cliente, porque es quien solicita el cálculo del total

LineaPedido posee los datos (cantidad y precio) requeridos para el cálculo, por lo que el patrón Experto le asigna esa responsabilidad. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Information Expert).)

30. En un sistema bancario, calcular el interés total de una cuenta requiere el saldo (que conoce Cuenta) y la tasa de interés (que conoce TipoDeCuenta); ninguna clase posee ambos datos por sí sola. Según el patrón GRASP Experto en Información, ¿cuál es la solución recomendada?

1. Crear una tercera clase sin datos propios que centralice el cálculo
2. Duplicar el atributo de tasa de interés dentro de la clase Cuenta
3. Asignar la responsabilidad a TipoDeCuenta, ya que fue la última clase creada en el diseño
4. Asignar la responsabilidad a Cuenta, pues puede obtener la tasa de TipoDeCuenta y ya conoce el saldo

Cuando la información está distribuida, Experto recurre a un 'experto parcial': la clase que puede colaborar con otra para reunir los datos necesarios, en este caso Cuenta. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Information Expert, experto parcial).)

31. Según el patrón GRASP Creador, la clase B debe encargarse de crear instancias de la clase A si se cumple, entre otras, la condición de que B...

1. Tiene el mayor número de métodos públicos
2. Contiene o agrega objetos de tipo A
3. Hereda directamente de la clase A
4. Implementa la misma interfaz que la clase A

Una de las condiciones del patrón Creador es que B contenga o agregue objetos de A, entre otras como registrar, usar íntimamente o poseer los datos de inicialización de A. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Creator).)

32. En un sistema de reservaciones, la clase Vuelo mantiene una colección de objetos Reservacion y almacena los datos necesarios para inicializarlos (fecha, asiento, pasajero). Según el patrón Creador, ¿qué clase debe crear los objetos Reservacion?

1. Pasajero, porque es quien solicita la reservación
2. Aerolinea, porque administra todos los vuelos del sistema
3. Vuelo, porque agrega y contiene los datos de la Reservacion
4. Asiento, porque es un atributo de la reservación

Vuelo cumple varias condiciones del patrón Creador: agrega, contiene y posee los datos de inicialización de Reservacion. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Creator).)

33. En un editor de dibujo vectorial, la clase Lienzo contiene y administra todos los objetos Figura que el usuario dibuja, y almacena los parámetros iniciales (posición, color) de cada figura nueva. Un desarrollador propone que la clase Figura se cree a sí misma porque conoce mejor sus propios atributos. ¿Qué patrón GRASP contradice esa propuesta y por qué?

1. Creador, porque Lienzo contiene y agrega instancias de Figura y posee los datos de inicialización
2. Alta Cohesión, porque Figura ya tiene demasiadas responsabilidades internas
3. Bajo Acoplamiento, porque Figura no debe conocer a Lienzo bajo ninguna circunstancia
4. Experto en Información, porque Figura es la única que conoce su propio color

El patrón Creador asigna la creación a la clase que agrega, contiene y posee los datos de inicialización del objeto creado (Lienzo), no necesariamente a la clase creada. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Creator).)

34. El patrón GRASP Bajo Acoplamiento tiene como objetivo principal...

1. Concentrar todas las validaciones del sistema en una sola clase controladora
2. Aumentar el número de métodos públicos que expone cada clase
3. Garantizar que cada clase implemente al menos una interfaz
4. Reducir la dependencia entre clases para facilitar el mantenimiento y la reutilización

Bajo Acoplamiento busca minimizar las dependencias entre clases para que un cambio en una tenga menor impacto en las demás. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Low Coupling); Stevens, Myers, Constantine (1974).)

35. Una clase ReporteVentas invoca directamente métodos internos de la clase ConexionBaseDatosMySQL en lugar de usar una interfaz genérica de acceso a datos. Si la empresa migra a otro motor de base de datos, esta decisión obligará a modificar ReporteVentas. ¿Qué patrón de diseño se violó?

1. Alta Cohesión
2. Bajo Acoplamiento
3. Experto en Información
4. Polimorfismo

Depender directamente de una implementación concreta en lugar de una abstracción incrementa el acoplamiento, contradiciendo el patrón Bajo Acoplamiento. (Larman, C. (2004). Applying UML and Patterns, 3a ed., cap. 17 (GRASP - Low Coupling).)