Patrones GRASP, primera parte

Definición de Patrones

Los desarrolladores orientados a objetos con experiencia acumulan un repertorio tanto de principios generales como de soluciones basadas en aplicar ciertos estilos que les guían en la creación de software. Estos principios y estilos, si se codifican con un formato estructurado que describa el problema y la solución, y se les da un nombre, podrían llamarse “Patrones”.

De manera mas simple un patrón es un par problema/solución con nombre que se puede aplicar en nuevos contextos, con consejos acerca de como aplicarlo en nuevas situaciones y discuciones sobre sus compromisos.


Un patrón es una descripción de un problema bien conocido que suele incluir:

  • Descripción
  • Escenario de Uso
  • Solución concreta
  • La consecuencias de utilizar este patrón
  • Ejemplos de implementación
  • Lista de patrones relacionados

Estos patrones, pueden ser clasificados y categorizados de acuerdo al uso que tendrán.

Hablando de UML uno de los más usados son los conocidos como patrones GRASP(Patrones para asignar responsabilidades).

A continuación un catálogo básicos de patrones(existen más), los cuales son los primeros cinco patrones GRASP:

  1. Bajo Acoplamiento.-Debe haber pocas dependencias entre las clases. Si todas las clases dependen de todas ¿cuanto software podemos extraer de un modo independiente y reutilizarlo en otro proyecto?.Para determinar el nivel de acoplamiento de clases, son muy buenos los diagramas de colaboración de UML. Uno de los principales síntomas de un mal diseño y alto acoplamiento es una herencia muy profunda. Siempre hay que considerar las ventajas de la delegación respecto de la herencia.
  2. Experto.-La responsabilidad de realizar una labor es de la clase que tiene o puede tener los datos involucrados (atributos) . Una clase, contiene toda la información necesaria para realizar la labor que tiene encomendada. Hay que tener en cuenta que esto es aplicable mientras estemos considerando los mismos aspectos del sistema:
    • Lógica de negocio
    • Persistencia a la base de datos
    • Interfaz de usuario
  3. Alta Cohesión.-Cada elemento de nuestro diseño debe realizar una labor única dentro del sistema, no desempeñada por el resto de los elementos y auto-identificable.

    Ejemplos de una baja cohesión son clases que hacen demasiadas cosas. En todas las metodologías se considera la refactorización. Uno de los elemento a refactorizar son las clases saturadas de métodos.Ejemplos de buen diseño se producen cuando se crean los denominados “paquetes de servicio” o clases agrupadas por funcionalidades que son fácilmente reutilizables (bién por uso directo o por herencia).

  4. Creador.-Se asigna la responsabilidad de que una clase B cree un Objeto de la clase A solamente cuando
    1. B contiene a A
    2. B es una agregación (o composición) de A
    3. B almacena a A
    4. B tiene los datos de inicialización de A (datos que requiere su constructor)
    5. B usa a A.

La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad,encapsulación y reutilización.

5.- Controlador .-Asignar la responsabilidad de controlar el flujo de eventos del sistema, a clases específicas. Esto facilita la centralización de actividades (validaciones, seguridad, etc.) . El controlador no realiza estas actividades, las delega en otras clases con las que mantiene un modelo de alta cohesión.Un error muy común es asignarle demasiada responsabilidad y alto nivel de acoplamiento con el resto de los componentes del sistema.

En proceso unificado, al construir el modelo de análisis, existen estereotipos predefinidos que favorecen la separación de entidades, mecanismos de interfaz y mecanismos de control.En conclusión el libro, llamado UML y Patrones (Craig Larman) en el capitulo 16 (GRASP:Diseño de objetos con responsabilidades)nos puede ayudar en el diseño y la identificación de las clases en base a su responsabilidad. Este Capitulo de este libro es muy bueno pero puede ser un poco denso para usuarios principiantes ….. aunque si comenzamos a leerlo al final no tiene desperdicio.

Referencia: UML y Patrones (Craig Larman) en el capítulo 16(GRASP: Diseño de objetos con responsabilidades) UML y Patrones (Craig Larman) en el capítulo 16(GRASP: Diseño de objetos con responsabilidades)

Notas relacionadas :

You can skip to the end and leave a response. Pinging is currently not allowed.

Deje una respuesta

Webdesign