GRASP: MS PATRONES PARA ASIGNAR RESPONSABILIDADES

22 Introduccin
Los cuatro ltimos patrones GRASP son: o Polimorfismo. o Indireccin. o Fabricacin Pura. o Variaciones Protegidas. Una frase corta como, Sugiero una Estrategia generada a partir de una Factorizacin para soportar Variaciones Protegidas y Bajo Acoplamiento con respecto a <X> revela mucha informacin sobre el diseo, puesto que el nombre de los patrones transmite de manera concisa un concepto de diseo complejo.

22.1 Polimorfismo
Problema: o Cmo manejar alternativas basadas en el tipo? Cmo crear componentes software conectables (pluggable)? Solucin: o Cuando las alternativas o comportamientos relacionados varan segn el tipo (clase), hay que asignar la responsabilidad para el comportamiento, utilizando operaciones polimrficas, a los tipos para los que vara el comportamiento. Discusin: o El polimorfismo es un principio fundamental para disear cmo se organiza el sistema para gestionar variaciones similares. o Segn el polimorfismo, un diseo basado en la asignacin de responsabilidades puede extenderse fcilmente para manejar nuevas variaciones. Contraindicaciones: o Dedicacin de un esfuerzo innecesario en la preparacin para le futuro diseo con polimorfismo en puntos de variacin que en realidad son improbables y nunca aparecern realmente. Beneficios: o Se aaden fcilmente las extensiones necesarias para nuevas variaciones. o Las nuevas implementaciones se pueden introducir sin afectar a los clientes. Patrones relacionados: o Variaciones Protegidas. o Patrones de diseo GoF = {Adaptator, Command, Composite, Proxy, Estado y Estrategia} Tambin conocido como; parecido a: o Eleccin del mensaje, No preguntes Qu clase?.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

22.2 Fabricacin Pura

Problema: o Qu objetos debern tener la responsabilidad cuando uno no quiere violar los objetivos de Alta Cohesin y Bajo Acoplamiento, u otros, pero las soluciones que ofrece el Experto (por ejemplo) no son adecuadas? Solucin: o Asignar un conjunto de responsabilidades altamente cohesivo a una clase artificial o de conveniencia que no representa un concepto del dominio del problema, algo inventado para soportar alta cohesin, bajo acoplamiento y reutilizacin. Discusin: o El diseo de los objetos se puede dividir en general en dos grupos: Los escogidos de acuerdo a una descomposicin de la representacin. Los escogidos segn una descomposicin del comportamiento. o Una Fabricacin Pura normalmente se organiza en base a funcionalidad relacionada y de este modo es un objeto centrado en la funcin o de comportamiento. Beneficios: o Alta Cohesin. o Potencial de reutilizacin. Contraindicaciones: o El abuso en la descomposicin de comportamiento en objetos de Fabricacin Pura. o Si se abusa, la Fabricacin Pura podra dar lugar a demasiados objetos de comportamiento son responsabilidades que no se colocaron con la informacin necesaria para su realizacin, lo que puede afectar negativamente al acoplamiento. o El sntoma habitual es que la mayora de los datos contenidos en los objetos se pasan a otros objetos para trabajar con ellos. Patrones y Principios Relacionados: o Bajo Acoplamiento.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

o o

Alta Cohesin. Todos los patrones de diseo GoF.

22.3 Indireccin
Problema: o Dnde asignar una responsabilidad, para evitar el acoplamiento directo entre dos o ms cosas? o Cmo desacoplar los objetos de manera que se soporte el bajo acoplamiento y el potencial para reutilizar permanezca ms alto? Solucin: o Asignar la responsabilidad a un objeto intermedio que medie entre otros componentes o servicios de manera que no se acoplen directamente. Discusin: o La mayora de los problemas en informtica se pueden resolver mediante otro nivel de indireccin. o El motivo para la indireccin normalmente es el Bajo Acoplamiento; se aade un intermediario para desacoplar otros componentes o servicios. Beneficios: o Disminuir el acoplamiento entre los componentes. Patrones y principios relacionados: o Variaciones Protegidas. o Bajo Acoplamiento. o Muchos patrones GoF = {Adaptador, Puente, Fachada, Observador y Mediador}.

22.4 Variaciones Protegidas

Problema: o Cmo disear objetos, subsistemas y sistemas de manera que las variaciones o inestabilidades en estos elementos no tengan un impacto no deseable en otros elementos? Solucin: o Identifique los puntos de variaciones previstas o de inestabilidad; asigne responsabilidades para crear una interfaz estable alrededor de ellos. Discusin: Mecanismos motivados por VP Mecanismos bsicos de Variaciones Protegidas VP motiva la encapsulacin de datos, interfaces, polimorfismo, indireccin y estndares. Diseos dirigidos por los datos Estos diseos cubren una amplia familia de tcnicas entre las que se encuentran la lectura de valores, rutas de fichero de clase, nombres de clase, procedentes de una fuente externa para cambiar el comportamiento o parametrizar un sistema de alguna manera en tiempo de ejecucin. Se protege al sistema del impacto de variaciones de datos , metadatos, registrando externamente la variante, leyndola y razonando sobre ella Bsqueda de servicios Esta bsqueda incluye tcnicas como la utilizacin de servicios de nombres o intermediarios para obtener un servicio (UDDI para los servicios Web). Diseos dirigidos por un intrprete Estos diseos comprenden los intrpretes de reglas externas, intrpretes de script, etc.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com

Diseos reflexivos o de meta-nivel Acceso uniforme Principio de Sustitucin de Liskov (PSL) PLS formaliza el principio de proteccin contra las variaciones en implementaciones diferentes de una interfaz, o una subclase que extiende una superclase. Informalmente el software (mtodos, clases, ) que hace referencia a un tipo T (alguna interfaz o superclase abstracta) debera trabajar correctamente o como se espera con cualquier implementacin o subclase de T que la sustituya, llammosla S. Diseos de ocultacin de la estructura Ley de Demeter (No hable con estraos) es evitar crear diseos que recorren largos caminos de la estructura de objetos y enva mensajes (o habla) con objetos distantes, indirectos (extraos). Un mecanismo para lograr proteger de los cambios en la estructura es aplicar las reglas de No Hable con Extraos. Establece que en un mtodo, solo deberan enviarse mensajes a los siguientes objetos: 1. El objeto this. 2. Un parmetro del mtodo. 3. Un atributo de this. 4. Un elemento de una coleccin que es un atributo de this. 5. Un objeto creado en el mtodo. La intencin es evitar el acoplamiento de un cliente con conocimiento de objetos indirectos y las conexiones entre objetos. Los objetos directos son conocidos del cliente, los objetos indirectos son extraos. Un cliente debera hablar con conocidos y evitar hablar con extraos. En general, cuanto ms lejos se recorre a lo largo de un camino, ms frgil es y, por tanto, es ms til ser conforme con el principio No Hable Con Extraos. Contraindicaciones: o Se definen dos puntos de cambio: Punto de variacin: variacin en el sistema actual, existente o en los requisitos. Punto de evolucin: puntos especulativos de variacin que podran aparecer en el futuro, pero que no estn presentes en los requisitos actuales. VP se aplica tanto a los puntos de variacin como de evolucin Una advertencia: algunas veces el coste de futuras necesidades especulativas en los puntos de evolucin pesa ms que el coste en el que se incurre por un diseo simple, ms frgil que se revisa cuando sea necesario en respuesta a verdaderas presiones de cambio. Es decir, el coste de disear la proteccin en los puntos de evolucin puede ser ms alto que rehacer un diseo simple. Beneficios o Se aaden fcilmente las extensiones que se necesitan para nuevas variaciones. o Se puede introducir nuevas implementaciones sin afectar a los clientes. o Se reduce el acoplamiento. o Puede disminuirse el impacto o coste de los cambios.

Longinos Recuero Bustos

Diseo del software 2012-13

http://longinox.blogspot.com