Patrones Grasp (Craig Larman) Parte I

Publicado: agosto 17, 2006 en Ingenieria de Software

Definicion 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

Lo patrones de GRASP, no compiten con los patrones de diseño….. los patrones de GRASP, nos guían para ayudarnos a encontrar los patrones de diseño (que son más concretos)…..
Ahora Veremos un catálogo de patrones, 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.

En Conclusión este libro, llamado UML y Patrones (Craig Larman) en el capítulo 16(GRASP: Diseño de objetos con responsabilidades) nos puede ayudar en nuestro diseño y a la identificación de las clases en base a su responsabilidades, Es un capítulo muy bueno pero puede ser un poco denso y cansador para usuarios principiantes, aunque una vez comenzemos a leer no habra ningún desperdicio de tiempo.

comentarios
  1. jorge dice:

    espero que me madnden un resumen

  2. ROQUE dice:

    CUAL ES LA DIFERENCIA ENTRE UN FLUJO ALTERNATIVO Y UNA EXCEPCIÒN

  3. Ana dice:

    Seguramente es un poco tarde para responder, y perdón por la intromisión. Según tengo entendido un flujo alternativo es un flujo que se sigue dependiendo de un valor condicional anterior. Por ejemplo, si ocurre A entonces sigo por Flujo1, si ocurre B entonces por el Flujo2, etc. En cambio una excepción es la denominación de un conjunto de acciones que se producen ante un evento inesperado, como es el caso de un error.
    Saludos

  4. Franco dice:

    excelente resumen !!!
    me dejó todo muy claro para empezar a averiguar en profundidad con respecto a los patrones de diseño.
    Un saludo desde chile

  5. Humberto dice:

    de donde puedo descargar este Libro en PDF ya sea en ingles o español ???
    humberthp@gmail.com

    Gracias

  6. uninorteño dice:

    las definiciones estan perfectas pero deberian haber colocado ejemplos

  7. aabascal@estudiantes.uci.cu dice:

    kyukuiluilio

  8. kriana dice:

    al fin entendí bajo acoplamiento y alta cohesion😀

  9. cesar dice:

    muchas gracias, soy principiante en el libro de Larman… y con este resumén ahora entiendo un poco más el capitulo 16 !!!

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s