Patrones de Diseño: Estructuras y Responsabilidades en el Desarrollo de Software

• Describe estructura recurrente de componentes comunicados.
• Resuelve problema de diseño en contexto particular.
• Esquema, refina subsistemas o componentes de Sw y relaciones.
• Menor que Pa arq, independiente de lenguajes de programación.
• No afecta estructura del sistema, sí del subsistema.
• Especifica nivel de detalle, no implementa comportamiento de componentes del subsistema.
• Base para buscar soluciones a problemas comunes en desarrollo de Sw o diseño de interacción o interfaces.

Para que sea Pa dis debe poseer características:

• Efectividad resolviendo problemas similares en otras ocasiones.
• Reusable, aplicable a diferentes problemas de diseño.

“Descripciones de objetos que se comunican y clases que son personalizadas para resolver un problema de diseño general en un contexto particular” (Gamma y otros, 1995)

• Programa para una interfaz, no para una implementación.

“Comience cualquier jerarquía que necesite para solucionar su problema con una clase abstracta, sin implementación de métodos. Que solo describa los métodos que debe soportar”

• Favorecer la composición frente a la herencia de clases.

“Construir objetos que contengan otros objetos. No cargue con todo el peso de heredar métodos que no necesita”

• Encuentre lo que varía y encapsúlelo.

“Lo que puede ser cambiado en su diseño encapsúlelo en una clase, para no tener necesidad de rediseñar”

Un patrón de diseño nos brinda las siguientes respuestas:

• Problema: ¿Qué problema de diseño soluciona?
• Solución: ¿Cómo solucionar el problema?
• Contexto: Precondiciones para que se pueda aplicar el patrón.
• Restricciones: ¿Qué afecta la aplicación del patrón?

Propiedades No Funcionales:

• Reutilización: permite que el código sea reutilizable.
• Facilidad de modificación: costo de cambio en el código de alguna funcionalidad sea mínimo.
• Facilidad de comprensión: ayuda a que el código sea legible y se entienda mejor su diseño.
• Robustez: la aplicación sea robusta, bien definida y diseñada.
• Eficiencia: permite que el sistema sea eficiente.
• Facilidad de uso: la aplicación de un patrón es simple, solo basta con adaptar las situaciones planteadas y la aplicación de cada patrón.

Patrones de Diseño: GRASP General Responsibility Assignment Software Patterns.

• Describen principios para asignar responsabilidades a objetos.
• Asignación de responsabilidad: obligación o contratos de clase.
• Dos clases de responsabilidades: Conocer y Hacer.

Conocer:

• Conocer la información privada del objeto.
• Conocer acerca de los objetos relacionados.
• Conocer acerca de lo que se puede calcular o derivar.

Hacer:

• Realizar algo el mismo.
• Iniciar una acción en otro objeto.
• Controlar o coordinar actividades en otros objetos.

¿Cuándo se asignan responsabilidades?

En la fase de análisis:

• Definición de servicios de componentes de arquitectura global.
• Definición de atributos de clases de modelo conceptual.
• Definición de diagramas de interacción, refinar modelo conceptual.

En la fase de diseño:

• Diseño estructural, refina modelo conceptual.
• Responsabilidades de conocer.
• Definición de métodos.

El patrón “Experto”

• Problema: ¿en qué debemos basarnos para asignar responsabilidades a las clases?
• Solución: asignar la responsabilidad al “experto en la información”.

El experto en la información es la clase que tiene la información necesaria para cumplir la responsabilidad.

Expresa que los objetos deben hacer las cosas relacionadas con la información que poseen.

El patrón “Creador”

• Problema: ¿quién es el responsable de crear una nueva instancia de una clase?
• Solución: B es responsable de crear una instancia de A si:
  • B agrega objetos de A.
  • B contiene referencias a objetos de A.
  • B almacena instancias de A.
  • B utiliza estrechamente objetos de A.
  • B tiene la información de inicialización que se necesita para crear un objeto de clase A.