Patrones fundamentales en el Diseño Orientado a Objetos (DOO)

El diseño orientado a objetos es una etapa fundamental en el desarrollo de sistemas orientados a objetos, sin embargo, por lo general, en la práctica se observa que no se le dedica el tiempo suficiente o bien es efectuada de una manera muy superficial. Es común observar una pequeña etapa de análisis de requisitos y un pasaje inmediato al proceso de programación.

Algunas veces para justificar esta superficialidad en cuanto a la manera de trabajar en la etapa de diseño, se atribuye a la falta de tiempo como causa principal. Sin embargo, sería más que beneficioso aplicar las buenas prácticas en cuanto a desarrollo de software para lograr productos de calidad.

Particularmente, durante la etapa de diseño se efectúan decisiones relativas a qué métodos se requerirán, dónde se los colocarán y cómo deberían interactuar los objetos, actividades nada triviales y muy importantes. Por tal motivo, sería altamente conveniente tener en cuenta algunos patrones de diseño fundamentales.

En la tecnología de objetos, un patrón es una descripción del problema y la solución, a la que se da un nombre, y que se puede aplicar a nuevos contextos; idealmente, proporciona consejos sobre el modo de aplicarlo en varias circunstancias, y considera los puntos fuertes y compromisos.[1]

Unos de los patrones fundamentales es el GRASP (Patrones de Principios Generales para Asignar Responsabilidades). En esta entrada se describirán cinco:

• Experto en información
• Creador
• Alta cohesión
• Bajo acoplamiento
• Controlador

Experto en información

• Problema: ¿Cuál es un principio para asignar responsabilidades a los objetos?
• Solución: Asignar una responsabilidad al experto en información (la clase que tiene la información necesaria para realizar la responsabilidad)

Si esta actividad se realiza bien, los sistemas tienden a ser más fáciles de entender, mantener y ampliar, y existen más oportunidades para reutilizar componentes en futuras aplicaciones.

El experto en información se utiliza con frecuencia en la asignación de responsabilidades; es un principio de guía básico que se utiliza continuamente en el diseño de objetos. El Experto no pretende ser una idea oscura o extravagante; expresa la “intuición” común de que los objetos hacen las cosas relacionadas con la información que tienen.

Se debe notar que el cumplimiento de la responsabilidad a menudo requiere información que se encuentra dispersa por diferentes clases de objetos.

Beneficios:

1. Se mantiene el encapsulamiento de la información, puesto que los objetos utilizan su propia información para llevar a cabo las tareas. Normalmente, esto conlleva un bajo acoplamiento, lo que da lugar a sistemas más robustos y más fáciles de mantener.
2. Se distribuye el comportamiento entre las clases que contienen la información requerida, por tanto, se estimula las definiciones de clases más cohesivas y “ligeras” que son más fáciles de entender y mantener. Se soporta normalmente una alta cohesión.

Creador

• ¿Quién debería ser el responsable de la creación de una nueva instancia de alguna clase?
• Asignar a la clase B la responsabilidad de crear una instancia de la clase A si se cumple una o más de los casos siguientes:
• B agrega objetos de A
• B contiene objetos de A
• B registra instancias de objetos de A
• B utiliza más estrechamente objetos de A
• B tiene los datos de inicialización que se pasará a un objeto de A cuando sea creado (por tanto, B es un Experto con respecto a la creación de A)

Si se asigna bien la responsabilidad de creación, el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.

Contraindicaciones: A menudo, la creación requiere una complejidad significativa, como utilizar instancias recicladas por motivos de rendimiento, crear condicionalmente una instancia a partir de una familia de clases similares basadas en el valor de alguna propiedad externa, etc. En estos casos, es aconsejable delegar la creación a una clase auxiliar denominada Factoria.

Alta cohesión

• Problema: ¿Cómo mantener la complejidad manejable?
• Solución: Asignar una responsabilidad de manera que la cohesión permanezca alta.

La cohesión es una medida de la fuerza con la que se relacionan y del grado de focalización de las responsabilidades de un elemento. Un elemento con responsabilidades altamente relacionadas, y que no hace una gran cantidad de trabajo, tiene alta cohesión. Estos elementos pueden ser clases, subsistemas, etc.

Una clase con baja cohesión hace muchas cosas no relacionadas, o hace demasiado trabajo. Tales clases no son convenientes, adolecen de los siguientes problemas:

1. Difíciles de entender
2. Difíciles de reutilizar
3. Difíciles de mantener
4. Delicadas, constantemente afectadas por los cambios.

Como regla empírica, una clase con alta cohesión tiene un número relativamente pequeño de métodos, con funcionalidad altamente relacionada, y no realiza mucho trabajo. Colabora con otros objetos para compartir el esfuerzo si la tarea es extensa.

Bajo acoplamiento

• Problema: ¿Cómo soportar bajas dependencias, bajo impacto del cambio e incremento de la reutilización?
• Solución: Asignar una responsabilidad de manera que el acoplamiento permanezca bajo.

El acoplamiento es una medida de la fuerza con que un elemento está conectado a, tiene conocimiento de, confía en, otros elementos. Un elemento con bajo acoplamiento no depende de demasiados otros elementos.

Una clase con alto acoplamiento confía en muchas otras clases. Tales clases podrían no ser deseables; algunas adolecen de los siguientes problemas:

1. Los cambios en las clases relacionadas fuerzan cambios locales
2. Son difíciles de entender de manera aislada
3. Son difíciles de reutilizar puesto que su uso requiere la presencia adicional de las clases de las que depende.

En general, las clases que son inherentemente muy genéricas por naturaleza, y con una probabilidad de reutilización alta, debería tener un acoplamiento especialmente bajo.

El caso extremo de bajo acoplamiento es cuando no existe acoplamiento entre clases. Esto no es deseable porque una metáfora central de la tecnología de objetos es un sistema de objetos conectados que se comunican mediante el paso de mensajes. Si el bajo acoplamiento se lleva al extremo, producirá un diseño pobre porque dará lugar a unos pocos objetos inconexos, saturados, y con actividad compleja que hacen todo el trabajo, con muchos objetos muy pasivos, sin acoplamiento que actúan como simple repositorios de datos.

Controlador

• Problema: ¿Quién debe ser el responsable de gestionar un evento de entrada al sistema?
• Solución: Asignar la responsabilidad de recibir o manejar un mensaje de evento del sistema a una clase que representa una de las siguientes opciones:
• Representa el sistema global, dispositivo o subsistema (controlador de fachada)
• Representa un escenario de caso de uso en el que tiene lugar el evento del sistema, a menudo denominado Manejador, Coordinador o Sesion (controlador de sesión o de caso de uso)
• Utilice la misma clase controlador para todos los eventos del sistema en el mismo escenario de caso de uso
• Informalmente, una sesión es una instancia de una conversación con un actor. Las sesiones pueden tener cualquier duración, pero se organizan a menudo en función de los casos de uso (sesiones de caso de uso)

Un controlador es un objeto que no pertenece a la interfaz de usuario, responsable de recibir o manejar un evento del sistema. Un controlador define el método para la operación del sistema.

La primera categoría de controlador es el controlador de fachada que representa al sistema global, dispositivo o subsistema. La idea es elegir algún nombre de clase que sugiera una cubierta, o fachada, sobre las otras capas de la aplicación, y que proporciona la llamada a los servicios más importantes de la capa de UI hacia las otras capas.
Los controladores de fachada son adecuados cuando no existen “demasiados” eventos del sistema, o no es posible que la interfaz de usuario redireccione mensajes de los eventos del sistema a controladores alternativos, como un sistema de procesamiento de mensajes.

Si se elige un controlador de caso de uso, entonces hay un controlador diferente para cada caso de uso. Nótese que no es un objeto del dominio; es una construcción artificial para dar soporte al sistema.

Un controlador de caso de uso es una alternativa a tener en cuenta cuando la asignación de responsabilidades a un controlador de fachada nos conduce a diseños con baja cohesión o alto acoplamiento, generalmente cuando el controlador de fachada se está “inflando” con excesivas responsabilidades.

El controlador recibe la solicitud del servicio desde la capa de UI y coordina su realización, normalmente delegando a otros objetos.

Referencias:
[1] LARMAN, Craig. UML y Patrones: Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Segunda edición. Madrid: Prentice Hall, 2001

Algunos links adicionales para continuar leyendo:

• Patrones de Diseño en aplicaciones Web con Java J2EE
• Patrones de diseño software

Si conoces algunos links relacionados al tema y piensas que pueden ser útiles, compartilos dejándolos en un comentario…

Advertisement