Friday, July 01, 2005

GOF(Parte I)

Saber o no saber GOF
Para mi, el problema no radica alli,
personalmente creo, que GOF es solo el acrónimo dado a Gang Of Four, o pandilla de los cuatro,
un pequeño grupo de gente incomprendida (como tantos que creo conocer), pero que realmente buscaba un bien comun, y no salir en las revistas junto con propagandas de "fumar es dañino para la salud..."

El problema en si, era tener que lidiar con cosas generalmente parecidas, pero que presentaban soluciones que terminaban quizá dependiendo hasta del desarrollador...(ya un amigo me decia, piensa tres horas, programa en una..., pero no, creo qe por fin logré entender la diferencia entre un analista y un programador...sin ofender claro)

El concepto de patron de diseño empezó a concebirse debido a que en la construcción de edificios se habian encontrado problemas similares, y era recomendable documentarlos para saber la solución, y aplicarla, ganando asi tiempo.

Partiendo por lo esencial, sabemos que es un patrón?
cuantos creemos saber que significa eso, la verdad muchos creen que es un término de Arquitectura de Software, pero el termino Patrón, existía ya desde antes, y semánticamente hablando, es una solución comprobada a un problema ya conocido.

Una solución, comprobada, para un problema ya conocido...

Nada mas -y a la vez, mucho mas- que eso, y se diferencia de lo que muchos llamamos best practice (buena práctica) en:

  • Ha contado con un proceso de identificación,
  • ha sido optimizado para ser lo mas reutilizable posible,
  • cuenta con un nombre, el cual fue la parte mas dificil de la definición; debido a que tenia que ser el mas apropiado (esto es una idea que debe tomarse hasta para definir una variable...)
  • tiene un objetivo, es decir resolver una grieta en nuestro diseño
  • con que otros patrones puede trabajar en conjunto?
  • busca, ser parte de un Diseño de Software Flexible.
  • lo mas importante para muchos, ¿donde puedo aplicarlo? =D

Es decir, los patrones pueden ser orientados a muchas cosas, por lo cual; existen patrones para acceder a datos, realizar casos de prueba, integrar aplicaciones, en fin...

El grupo de los cuatro, se encargó de resumir un conjunto de patrones para la ajustada fase de Diseño de Software.

Los GOF Patterns, o el conjunto de patrones que el grupo de los cuatro trajo consigo, fueron presentados bajo:

- Patrones de Creación; dentro de los cuales hay patrones que abordan problemas comunmente encontrados al momento de decidir, donde, como y cuando crear objetos.

- Patrones Estructurales (Composición); aquí se encuentran los que sirven para resolver los problemas que se tienen al trabajar con interacción entre objetos (seria raro no encontrarla), o cuando estos realizan trabajo en conjunto (si no encontramos esto...de que estamos hablando?)

- Patrones de Comportamiento; aquí el conjunto de patrones que seran usados cuando se tengan que resolver problemas afines a las caracteristicas que deba tener un objeto.

Patrones de Creación
Los que pueden encontrarse son los siguientes (los nombres de los patrones los dejo en ingles, para no perder compatibilidad binaria xD)

1. - Abstract Factory;
El primero de la lista, usado para resolver problemas como
"quiero crear un conjunto de objetos que sean independientes del cliente, es decir, que cuando yo quiera, cambie de conjunto de objetos y el cliente no sienta la pegada!"
Por ejemplo; Jimmy, un amigo, esta renegando pues le encomendaron la tarea de trabajar ahora con MSAccess en vez de MSSqlServer, como venia ocurriendo hasta antes del pedido,

la aplicación fue desarrollada en .net(quien lo hizo?, nadie quiere decir xD), pero accede directamente via objetos como sqlConnection, sqlCommand, etc...
la tarea en resumen es usar oledbClient en vez de sqlClient, no parece complicado, pues para nuestra suerte (o la de Jimmy) hay mucha similitud entre ambas colecciones, a menos que trabaje con sp's alli si hay mas trabajo... (en acces no hay sps...)
Aplicando el patrón en mención, el problema se hubiera evitado usando una colección genérica, que de acuerdo a condiciones dadas (quizá por un archivo de configuración) direccione al trabajo con una coleccion en particular (es masomenos lo que se hace en DAAB)

2. - Builder;
Es una particularidad del Abstract Factory, lo que busca es el diseño flexible de un objeto que va a ser consumido por terceros;
El objeto, dependiendo de su creación, tendrá un comportamiento diferente, pero los consumidores no deberan ser afectados por ese cambio.
Además, lo que se busca es que el objeto creador este separado de los objetos a crearse, o como dicen la representacion (particular y ya no abstracta)

Un ejemplo en el que pude aplicar este patrón, fue cuando me pidieron un objeto para guardar registro de algunas acciones del usuario (un log), el objeto debía tener opción de registrar tanto en base de datos/archivo de texto/event view/y via email. todo dependiendo de la configuración del mismo.
Hay muchas formas de resolver el problema, por ejemplo antes de ejecutar cada método revisar la configuración y ejecutar la funcionalidad adecuada.
Pero esto seria algo ineficiente (algunos dirían hasta poco elegante), dado a que se estaria preguntando por la condicion cada vez que se haga una llamada a los metodos.

Lo que se hace al igual que el patrón anterior es trabajr con un direccionador que apuntará a objeto genérico (para el caso anterior se trabajaba hasta con una colección genérica, acá se omite esa parte...)
Este objeto se encargará de hacer las creación de un objeto particular (Es por ello el nombre de Builder). El direccionador será el que le indique con que objeto en particular se trabajará.

3.- Factory Method.-
Una variante en lo que respecta a creacion, aqui ya no se trabaja con un creador separado de la representación, son las clases derivadas las que deciden la implementación particular.
A diferencia del anterior, ya no se tiene el direccionador, se trabaja con el creador directamente.
Esto permite en una misma sección con diferentes instancias del mismo objeto (los cuales asu vez tienen diferente comportamiento)

4.- Prototype.-
Usado cuando es necesario trabajar con varias instancias de un mismo objeto, pero se busca ademas cierta independiencias entre estos,
Se trabaja con clonaciones de un objeto en particular.

5.- Singleton.-
Cuando se quiere trabajar con solo una instancia de un objeto, este es por cierto el patron que casi siempre el primero en ser mencionado...
Un lugar donde podria ser aplicado es cuando se tienen opciones de menú, y se quiere que al hacer click sobre el mismo, se muestre solo un formulario asociado.

Comentarios
No pense que llegaría hasta esta sección. espero con las siguientes entregas (pues tengo planeada que sean tres...), completar el resto de patrones.
Pueden encontrar bastante info en google ("C# patterns"), aunque la aplicabilidad vale para cualquier plataforma.
Este link es muy bueno

http://www.dofactory.com/Patterns/Patterns.aspx
El libro de GOF, es muy bueno...,

Este post si tuvo historia, ha demorado mas de lo que pensé y tuvo un accidente cuando estaba terminando por primera vez
(lo terminé 3 julio 2005)

say no more...

J.

4 comments:

Anonymous said...

Holas, un comentario constructivo y espero productivo..., estas hablando de Diseño, el Analista(ROL) no tiene q ver con el Diseño( solo maneja CU y ashi termina su ROL, Analizar), a lo mucho llega a ver Clases Conceptuales..., GOF trata de clases de Especificacion e Implementacion; es el Arquitecto(ROL) (quien prioriza los CU y da vida al Diseño) o Diseñador de Software ... sin ofender porsupuesto

Jesus Alviño armadar_26@hotmail.com

Anonymous said...

Estimado Jesús,
no he ahondado en eso, pues la idea era plantear el concepto general, si me gastaba en definir roles y demas cosas, pues, nunca hablaba de GOF.

un consejo, hasta de un conejo.
(por cierto, no te recomendaria dejar tu correo electronico en la red, hay demasiados locos y programas de spam en busca de nuevos clientes)


PD: me sorprende, ha pasado tanto tiempo para este post...

Anonymous said...

bien conejo acepto tu consejo ;) pero me parecio conveniente aclarar ese punto ya q como tu sabras es un tema muy debatible y poco esclarecido, puse mi msn porsia esq me da flojera inscribirme.

PD estaba buscando temas de arquitectura, y me gustaria debatir y aprender esto con la gentita, si conoces una comuna exclusiva de arquitectura te agradeceria mucho "aprendo lo q no se, comparto lo q se" saludos...

Anonymous said...

tanto como tu y jesus estan en lo correcto..

cazador_rebelde@hotmail.com