Patrones de Diseo

Patrones de DiseoIntroduccin1Introduccin a Patrones de DiseoAlguien ha resuelto ya tus problemasEl por qu y el cmo podemos explotar la sabidura y lecciones aprendidas por otros desarrolladores que han pasado por los mismos problemas de diseo y han sobrevividoBeneficios de los patrones de diseo Veremos algunos principios OO claveLa mejor manera de usar patrones es cargarlos en tu mente y reconocer lugares en tu diseo y en aplicaciones existentes donde poder aplicarlosNo se reutiliza cdigo, se reutiliza experiencia 2Todo empieza con un simple juego

Joe trabaja para una compaa que se dedica a crear juegos de simulacin de estanques de pato. El juego muestra una gran variedad de especies, nadando y haciendo graznidos.El diseador inicial del sistema utiliz tcnicas estndares OO y cre una superclase Pato de la cual las subclases de Pato heredan

3Todo empieza con un simple juego

Todos los patos nadan y graznan, la superclase se encarga de la implementacin

Cada subtipo es responsable de implementa el mtodo Mostrar()

El mtodo Mostrar() es Abstracto, ya que todos los subtipos de Pato se ven de manera distinta

Muchos otros tipos de patos heredan de la clase Pato

4Todo empieza con un simple juegoEn el ltimo ao, la compaa ha tenido bastante presin debido a sus competidores. Despus de una lluvia de ideas, los ejecutivos de la compaa piensan que es hora de innovar. Ellos necesita algo realmente sorprendente para mostrar en la reunin de inversionistas la prxima semana5Ahora necesitamos que los patos VUELENLos ejecutivos decidieron que patos voladores es justamente lo que esta aplicacin necesita para vencer a sus competidores. Y por supuesto, la jefa de Joe les dijo que no era problema para Joe, y que terminara en una semana. Despus de todo dijo la jefa Joe es un programador OO Qu tan difcil puede ser?6Ahora necesitamos que los patos VUELEN

Lo que queremosSolo necesito aadir un nuevo mtodo llamado Volar() a la clase Pato y los dems heredarn automticamente. Ahora es mi oportunidad para mostrar realmente mi genialidad en la programacin OO7Ahora necesitamos que los patos VUELEN

Lo que Joe agreg

Todas las subclases heredan Volar()

Otros tipos de Pato

8Pero algo sali mal muy mal

Joe, estoy en la reunin de inversionistas, estamos revisando el demo del juego, y hay Patos de Goma volando por todos lados. Es una broma o que?

9Qu pas?Joe nunca not que no todas las subclases de pato deben Volar. Cuando Joe agreg nuevo comportamiento a la superclase, tambin estaba agregando comportamiento no apropiado a las subclases. Ahora tiene objetos inertes volando en el juego.

Una actualizacin localizada al cdigo caus un efecto secundario no local (patos de goma voladores) 10Qu pas?

Poner el comportamiento Volar() en la superclase, le dio habilidad de vuelo a TODOS los patos, incluyendo a los que no deberan hacerlo

Patos de goma no graznan, el comportamiento es sobrescrito a Chillar

11Qu pas?

Lo que l pens que era un buen uso de herencia con el propsito de reutilizacin no result tan bueno cuando lidiamos con mantenimientoOK, hay una pequea falla en mi diseo. No se por qu no le pueden llamar una nueva funcin. Es simptico12Joe piensa en herencia

Podra sobrescribir Volar() en el pato de goma como lo hice con Graznar13Joe piensa en herencia

Pero que pasara si aumentamos patos seuelo de madera en el futuro. Ellos no vuelan ni graznanEsta es otra clase posible en la jerarqua; y notemos que al igual que el pato de goma, tampoco vuela, pero tampoco grazna14EjercicioA. El cdigo se duplica en las subclasesB. Cambios en tiempo de ejecucin son difcilesC. No podemos hacer que los patos bailenD. Se complica obtener conocimiento del comportamiento de todos los patosE. Los patos no pueden volar y graznar al mismo tiempoF. Los cambios en el cdigo podran afectar a otros patos sin intencinDe las siguientes opciones elija cules serian las desventajas de utilizar herencia en el ejemplo anterior

15Y si usamos una Interfaz?Joe se dio cuenta que la herencia probablemente no era la respuesta. Recibi un memo de los ejecutivos diciendo que quieren actualizar el producto cada seis meses (de maneras que ellos an no han decidido)Joe sabe que las especificaciones seguirn cambiando y ser forzado a revisar y probablemente actualizar Volar() y Graznar() por cada subclase de Pato que se vaya a crear para siempre!l necesita una manera ms limpia de hacer que solamente algunos ( no todos) los tipos de patos vuelen y graznen16Y si usamos una Interfaz?

Podra sacar el mtodo Volar() de la superclase Pato y hacerla una interfaz de esa manera nicamente los patos que quieran volar implementan la interfaz y de paso hago otra interfaz para Graznar ya que no todos los patos graznan17Que opinas de este diseo?

18

Es la idea ms tonta que se te ha ocurrido. Cdigo Duplicado. Si creas que sobrescribir unos cuantos mtodos era un error, cmo te sentirs cuando tengas que cambiar el comportamiento de vuelo de las 48 subclases de pato?19Qu haras t si fueras Joe?Sabemos que no todas las subclases deben tener comportamiento de vuelo y graznido as que implementar herencia no es la respuesta correcta.Y mientras que las interfaces IVolar e IGraznar resuelven parte del problema (Ej: patos de goma no vuelan), estas destruyen la reutilizacin del cdigo para esos comportamientos creando otra pesadilla diferente de mantenimiento.Por supuesto puede haber ms de un tipo de vuelo, incluso entre patos que si vuelan

20Qu haras t si fueras Joe?En estos momentos debemos estar esperando que un Patrn de Diseo llegue cabalgando en un caballo blanco a salvar el da Pues No, qu diversin habra en ello?Vamos a solucionar las cosas a la manera antigua, aplicando buenos principios de diseo OO21

No sera hermoso si existiera una manera de construir software que cuando se necesiten hacer cambios, lo podamos hacer con el menor impacto posible en el cdigo existente? Podramos pasar menos tiempo arreglando cdigo y ms tiempo haciendo que el programa haga cosas nuevas y mejoresCul es la nica cosa con la que puedes contar en el desarrollo de software?EL CAMBIOUtilizar un espejo para ver la respuesta23La constante en desarrollo de softwareNo importa dnde trabajesNo importa qu construyesNo importa qu lenguaje utilicesNo importa qu tan bien diseada este una aplicacin

Con el tiempo una aplicacin debe crecer y cambiar o sino morir24EjercicioMuchas cosas pueden crear cambios. Pensemos en razones que hayan disparado este comportamiento en nuestras aplicaciones. Ej:Mis clientes o usuarios decidieron que queran algo diferente o nueva funcionalidadMi compaa decidi comprar una nueva base de datos y tambin est comprando datos de proveedores en otro formato. Argh!

25Enfocarse en el problemaAhora sabemos que el uso de la herencia no funcion muy bien, ya que el comportamiento de pato sigue cambiando en todas sus subclases y no es apropiado que todas las subclases tengan esos comportamientos.Las Interfaces sonaban prometedoras al principio solo patos que deban volar Volarn- pero como en las interfaces no se implementa cdigo, no existe la reutilizacin de cdigo.

26Enfocarse en el problemaY esto quiere decir, que cuando se necesite modificar un comportamiento, estamos forzados a rastrear y cambiarlo en todas las diferentes subclases donde ese comportamiento se haya definido (probablemente introduciendo nuevos errores en el camino!)Por suerte, hay un principio de diseo justamente para estas situaciones

27Principio de diseo

Identifica los aspectos de tu aplicacin que varan y sepralos de aquellos que permanecen igual

Nuestro primer principio de diseo. (aunque ya fue visto en otra poca)28Enfocarse en el problemaEn otras palabras, si tenemos algn aspecto de nuestro cdigo que est cambiando, por ejemplo nuevos requerimientos, entonces sabremos que existe un comportamiento que necesita ser extrado y separado de todo lo que no cambia.

Otra manera de pensarlo es: tomar las partes que varan y encapsularlas, para que despus se puedan alterar o extender sin afectar a las partes que no varan.

A pesar de ser un concepto simple, forma la base de casi todo patrn de diseo. Todos los patrones proveen una manera de dejar que algunas partes de un sistema varen independientemente de las dems.29Toma las partes que varan y encapslalas para que as no afecten al resto de tu cdigo.

El resultado? Menos consecuencias no intencionales al cambiar cdigo y ms flexibilidad en tus sistemasSeparando lo que cambia de lo que se queda igualDnde empezamos? Segn lo visto, aparte de los comportamientos Volar() y Graznar(), la clase Pato funciona bien y parece que no hay otras partes de ella que varen o cambien frecuentemente.As que, aparte de algunos cambios, vamos a dejar a la clase pato en paz.Ahora, para separar las partes que cambian de aquellas que no, vamos a crear dos conjuntos de clases (separadas totalmente de Pato), una para Volar y otra para Graznar. Cada conjunto de clases representar las implementaciones de su comportamiento respectivo. Por ejemplo, una clase implementa graznar, otra implementa chillar y otra implementa silencio

31Separando lo que cambia de lo que se queda igualSabemos que Volar() y Graznar() son las partes de la clase Pato que varan entre los patos

Para separar estos comportamientos de la clase Pato, sacaremos ambos mtodos de la clase Pato y crearemos nuevas clases para representar cada comportamiento32Separando lo que cambia de lo que se queda igual

La clase Pato es an la superclase de todos los patos, pero sacamos los comportamientos y los ponemos en otra estructura de clasesAhora Volar y Graznar cada una tiene su propio conjunto de clasesVarias implementaciones de comportamientos vivirn aqu33Diseando los comportamientos de PatoCmo vamos a disear un conjunto de clases que implementen los comportamientos de volar y graznar?

Debemos mantener las cosas flexibles, despus de todo, fue la inflexibilidad en los comportamientos de los patos la que nos meti en problemas en primer lugarSabemos que debemos asignar comportamientos a las instancias de Pato, por ejemplo, tal vez queramos instanciar un nuevo pato de goma y darle un tipo de comportamiento de vuelo especfico al iniciarlo

34Diseando los comportamientos de PatoY ya que estamos por all, por qu no asegurarnos de poder cambiar este comportamiento dinmicamente?En otras palabras, debemos incluir mtodos o propiedades de asignacin en la clase Pato para que podamos cambiar los comportamientos de las subclases en tiempo de ejecucinDados estos objetivos, veamos el segundo principio de diseo35Principio de diseo

Programa a una interfaz no una implementacin

36Diseando los comportamientos de PatoUtilizaremos una interfaz para representar cada comportamiento, por ejemplo Vuelo y Graznido y cada implementacin de un comportamiento va a implementar una de estas interfaces

Entonces, esta vez no ser la clase Pato ni sus subclases las que implementarn las interfaces de vuelo y graznido. En lugar de ello crearemos un conjunto de clases cuya nica razn de existir es la de representar un comportamiento (por ejemplo Chillar), y son estas clases en lugar de los patos, las que implementarn el comportamiento de una interfaz37Diseando los comportamientos de PatoEsto contrasta bastante la manera como hemos estado trabajando hasta ahora, donde un comportamiento proviene de una implementacin concreta en la superclase Pato, o dando una implementacin especializada en la misma subclase. En ambos casos estbamos a expensas de una implementacin.Estbamos encerrados al tratar de utilizar la implementacin especfica y no haba espacio para un cambio de comportamiento (excepto escribir ms cdigo)Con nuestro nuevo diseo, las subclases de Pato utilizarn un comportamiento representado por una interfaz (IGraznido e IVuelo), pero la implementacin real del comportamiento, es decir, el cdigo del comportamiento concreto, no estar encerrada en las subclases de Pato38Diseando los comportamientos de Pato

De ahora en adelante, los comportamientos de un Pato van a vivir en una clase separada una clase que implementa una interfaz de comportamiento particular.

De esa manera, las subclases de Pato no necesitarn conocer ningn detalle de implementacin para su propios comportamientos.No veo por qu tenemos que utilizar una interfaz para el comportamiento de Vuelo. Podemos hacer exactamente lo mismo con una superclase abstracta. No era el objetivo utilizar polimorfismo?

Programar a una interfaz significa programar a un supertipoLa palabra interfaz est sobrecargada aqu ya que existe el concepto de interface, y existe el constructo interface para los lenguajes OO. Podemos programar a una interfaz, sin necesidad de usar una ya que el objetivo es explotar el polimorfismo programando a un supertipo y de esa manera el objeto real que es ejecutado no quede encerrado en el cdigoPodramos volver a escribir el principio Programar a un Supertipo de la siguiente manera : El tipo (de datos) de las variables declaradas debera ser un supertipo, generalmente una clase abstracta o una interfaz, para que los objetos asignados a estas variables puedan ser de cualquier implementacin concreta del supertipo, lo que significara que la clase que las declara (a las variables) no tienen que conocer los tipos de objetos reales!Tal vez ya sepas esto, pero para estar seguros de que todos estamos en hablando de lo mismo

Simple ejemplo - PolimorfismoEste es un ejemplo de como utilizar un tipo polimrficamente.Imagina una clase abstracta Animal, con dos implementaciones concretas, Perro y Gato

Supertipo Abstracto (puede ser una clase abstracta o una interfaz

Implementaciones concretasSimple ejemplo - PolimorfismoProgramar a una implementacin sera:

Perro p = new Perro();p.Ladrar();

Declarar la variable p como tipo Perro (una implementacin concreta de Animal) nos hace codificar a una implementacin concreta a la fuerza

Simple ejemplo - PolimorfismoPero Programar a una interfaz/supertipo sera:

Animal animal = new Perro();Animal.HacerUnSonido();

Sabemos que es un perro, pero podemos utilizar la referencia animal Polimrficamente

Simple ejemplo - PolimorfismoMejor an, en lugar de escribir a la fuerza la instanciacin del subtipo (new Perro()), asigna la implementacin concreta en tiempo de ejecucin

Animal animal = Obtener Animal();animal.HacerUnSonido();

No sabemos QU animalsea todo lo que nos importa es que sepa hacer un sonido

46Implementar los comportamientos del Pato

IVuelo es una interfaz que todas las clases de vuelo implementan. Todas las nuevas formas de vuelo necesitan implementar el mtodo Volar

De igual manera para el comportamiento de graznido

Esta es la implementacin de vuelo para todos los patos que tienen alas

Y esta es la implementacin para los patos que no vuelan

47Implementar los comportamientos del PatoCon este diseo, otros objetos pueden reutilizar Volar y Graznar ya que estos comportamientos no estn escondidos dentro de los Patos!Podemos aumentar nuevos comportamientos sin modificar ningn otro ya existente o tocar ninguna clase Pato que utiliza estos comportamientos Es decir que obtenemos los beneficios de REUTILIZACIN sin la carga que viene con la herencia

48Debo implementar mi aplicacin primero, ver donde cambian las cosas y luego regresar y separar/encapsular esas cosas?

No siempre; generalmente cuando estamos diseando una aplicacin, anticipamos estas reas que van a variar y luego construimos el cdigo que hace ganar flexibilidad. Nos daremos cuenta que los principios y patrones pueden ser aplicados en cualquier etapa del ciclo de desarrollo49Debemos hacer Pato una interfaz tambin?En este caso no. Como veremos ms adelante una vez que tengamos todo junto, nos beneficiaremos teniendo a Pato como Clase y sus subtipos , como Pato Colorado, heredando los mtodos y propiedades comunes.Ahora que hemos quitado lo que vara de la herencia de Pato, obtenemos los beneficios de esta estructura sin los problemas que conllevan.50Se siente extrao tener una clase que solo sea un comportamiento. No se supone que las clases representan cosas? No se supone que las clases tienen estados y comportamientos?En un sistema OO, s, las clases representan cosas que generalmente tienen estados ( las variables de instancia) y mtodos.Y en este caso, las cosas que representa es un comportamiento. Pero inclusive un comportamiento puede tener estado y mtodos; un comportamiento de vuelo podra tener variables de instancia representando los atributos del comportamiento vuelo (aletazos por minuto, altitud mxima, velocidad, etc)51EjercicioUsando el diseo anterior, qu tenemos que hacer si necesitamos volar con propulsor?Una clase que podra utilizar el comportamiento graznar52Integrando el comportamiento de PatoLa clave es que un Pato ahora delegar sus comportamientos de vuelo y graznido, en lugar de usar mtodos definidos en la misma clase Pato ( o subclase)53Integrando el comportamiento de Pato Primer PasoPrimero agregamos dos variables a la clase Pato llamadas Vuelo y Graznido como interfaces (no implementaciones concretas)Cada objeto pato le dar valor a estas variables polimrficamente para referenciar el comportamiento especfico que desee en tiempo de ejecucin (volar con alas, chillar, etc)Tambin quitamos los mtodos volar y graznar de la clase Pato (y cualquier subclase) ya que hemos movido estos comportamientos a las clases comportamiento de vuelo y graznidoReemplazaremos los mtodos Volar y Graznar en la clase Pato con dos mtodos similares llamados IniciarGraznido e IniciarVuelo(), luego veremos cmo los utilizaremos54Integrando el comportamiento de Pato Primer Paso

Las variables que representan comportamiento son declaradas como comportamientos de tipo INTERFAZEstos mtodos reemplazan a Volar() y Graznar()Las variables instancia mantienen una referencia a un comportamiento especfico en tiempo de ejecucin

Integrando el comportamiento de Pato - Segundo

Implementamos los mtodosPara graznar, un Pato solo le permite al objeto referenciado en la variable que haga la operacin No importa que tipo de objeto sea, nicamente nos interesa que sepa graznarCada Pato tiene una referencia a algo que implementa la interfaz IGraznidoEn lugar de manejar el comportamiento de Graznar por si mismo, el objeto Pato delega ese comportamiento al objeto referenciado por el comportamiento IGraznido

56Integrando el comportamiento de Pato - TerceroOk, es hora de preocuparnos cmo se asignan los valores de las variables Vuelo y Graznido

Recordemos que este pato hereda sus instancias de comportamiento de la clase PatoUn Pato Gargantilla utiliza la clase GraznarNormalmente para manejar sus graznidos, por eso cuando la operacin IniciarGraznido() es llamado, la responsabilidad es delegada al objeto GraznarNormalmente y obtenemos un hermoso graznido57IntegrandoEntonces el graznido de un pato colorado es tan real como el de cualquier pato, no es un chillido, no es un silencio. Entonces qu pas aqu? Cuando un PatoColorado es instanciado, su constructor inicializa su variable de comportamiento de graznido heredada a una nueva instancia de GraznarNormalmente (que es una implementacin de IGraznido)

Lo mismo es cierto para el comportamiento de vuelo

Un momento, no habamos dicho que NO debemos programar a una implementacin? Y qu estamos haciendo en ese constructor? Estamos haciendo una nueva referencia a la clase concreta GraznarNormalmente!Bien observado, eso es exactamente lo que estamos haciendo por ahora.Ms adelante conoceremos ms patrones que nos ayudarn a arreglar este problema.An as, notemos que asignando los comportamientos a una clase concreta (instanciando una clase comportamiento como GraznarNormalmente y la asignamos a nuestra variable), podramos fcilmente cambiarlo en tiempo de ejecucin.Y por ende, an tenemos mucha flexibilidad, lo nico malo es que estamos realizando un trabajo muy pobre al inicializar las variables de manera flexible. Pero si lo pensamos un poco, y notamos que nuestras variables de comportamiento son de tipo interfaz, podramos (a travs de la magia del polimorfismo) asignar dinmicamente un comportamiento distinto en tiempo de ejecucin.Tomemos un tiempo y pensemos cmo implementaramos un pato para que su comportamiento pueda cambiar en tiempo de ejecucin60EjerciciosCrear y compilar la clase Pato y una clase que herede de ella (Pato Gargantilla por ejemplo)Crear y compilar las interfaces de comportamiento y dos implementaciones para vuelo y tres para graznidoCrear una clase de prueba donde se compruebe el cdigo.Darle un valor de forma dinmica a una prueba (vuelo o graznido)

Vista panormica de los comportamientos encapsuladosOk, ahora que hemos tocado el diseo del simulador, es hora de regresar al inicio y mirar la panormica.

A continuacin veremos la estructura de clases. Tendremos todo lo que estamos esperando: patos extendiendo Pato, comportamientos de vuelo implementando IVuelo y comportamientos de graznido implementando Igraznido.Notemos tambin que hemos empezado a describir las cosas un poco diferente. En lugar de pensar en comportamientos de patos como un conjunto de comportamientos, ahora lo pensamos como una familia de algoritmos.

Vista panormica de los comportamientos encapsuladosPensndolo un poco, los algoritmos representan las cosas que un pato podra hacer (diferentes maneras de graznar o volar), pero podramos as mismo utilizar la misma tcnica para un conjunto de clases que implementan las diferentes maneras de calcular los impuestos de ventas por pas.

Prestemos mucha atencin a las relaciones entre las clases. De hecho podemos ir corrigiendo las relaciones apropiadas (Es-un/a, Tiene-un/a e implementa) en cada flecha del diagramaComportamiento encapsulado

Un Cliente utiliza una familia de algoritmos encapsulada para graznar y volarEstos comportamientos algoritmos son intercambiables

Tiene-un puede ser mejor que Es-unLa relacin TIENE UN es muy interesante, cada pato tiene una variable de comportamiento de vuelo y graznido al cual se le delegan las operaciones volar y graznarCuando unimos clases de esta manera estamos usando composicin. Los patos son compuestos con el objeto de comportamiento correcto, en lugar de heredarlosta es una tcnica importante, y de hecho, ya estamos usando nuestro tercer principio de diseo:

Principio de diseo

Favorecer a la composicin sobre la herencia

Tiene-un puede ser mejor que Es-unComo hemos visto, crear sistemas utilizando composicin nos da mucha ms flexibilidad. No solo permite encapsular familia de algoritmos en su propio conjunto de clases, sino que te permite cambiar comportamientos en tiempo real mientras los objetos que estemos componiendo implementen la interfaz de comportamiento correcta.La composicin se utiliza en muchos patrones de diseo y veremos algunas de sus ventajas y desventajas ms adelante

Maestro y Estudiante

Maestro: Saltamontes, dime qu has aprendido de las maneras Orientadas a Objeto.Estudiante: Maestro, he aprendido que la promesa de la orientacin a objeto es la reutilizacin.Maestro: Saltamontes, continuaEstudiante: Maestro, a travs de la herencia todas las cosas buenas pueden ser reutilizadas y de esa manera podemos cortar el tiempo de desarrollo como cortar bamb en el bosque.Maestro: Saltamontes, se desperdicia ms tiempo en el cdigo antes o despus de que se complete el desarrollo?Estudiante: La respuesta es despus, Maestro. Siempre gastamos ms tiempo manteniendo y cambiando el software que al inicio.Maestro: Entonces saltamontes, debera el esfuerzo enfocarse en la reutilizacin por encima de la mantenibilidad y extensibilidad?Estudiante: Maestro, yo creo que hay verdad en eso.Maestro: Puedo ver que an tienes mucho que aprender. Quiero que vayas a meditar sobre la herencia an ms. Como has visto, la herencia tiene sus problemas, y existen otras maneras de lograr la reutilizacinEjercicioReclamo es un dispositivo que los cazadores utilizan para imitar el llamado de los patos (graznido). Cmo implementaramos un reclamo que NO herede de la clase Pato?Hablando de patrones de diseo Hemos aplicado nuestro primer patrn de diseo el patrn STRATEGY. As es, ya hemos utilizado el patrn Strategy para rehacer el juego de estanque.Gracias a este patrn, el simulador est listo para cualquier cambio gerencia quiera realizar prximamente.Y ahora que tomamos el camino largo para aplicarlo, aqu est la definicin formal de este patrn: Felicitaciones en tu primer patrn

El patrn StrategyEl Patrn Strategy define una familia de algoritmos, encapsula cada uno de ellos, y los hace intercambiables. Strategy deja que los algoritmos varen independientemente de los clientes que lo utilizan.Utiliza ESTA definicin cuando quieras impresionar a tus amigos o quieras influenciar a un ejecutivoRompecabezasEn el siguiente ejemplo encontraremos clases e interfaces desordenadas pertenecientes a un juego de aventuras, clases de personajes y comportamiento de armas que cada personaje puede usar en el juego. Cada personaje puede hacer uso de un arma a la vez, pero puede hacer el cambio de armas en cualquier momento durante el juego. Tu debes arreglar todoOrdenar las clasesIdentificar una clase abstracta, una interfaz y ocho clasesDibujar flechas entre las clasesHerencia Interfaz Tiene unColocar el mtodo setArma() (o el Set de la propiedad Arma) en la clase correcta

Rompecabezas

Necesito una porcin de queso crema y mermelada en pan blanco, un helado de vainilla con decorado de chocolate, un sndwich de queso a la parrilla con tocino, una ensalada de atn con pan tostado, un helado banana Split con dos bananas y un caf con crema y dos cucharadas de azcar, oh y tambin coloca una hamburguesa en la parrilla!Dame un QJ. En Blanco, y Blanco y negro, un Jack Benny, una radio, y un bote de casa, un caf regular y una parrillaConversacin en un restaurante localAliceFloCul es la diferencia entre las dos conversaciones?Nada! Son exactamente la misma orden, excepto que la primera persona est utilizando el doble de palabras y tentando la paciencia de el cocinero.Qu tiene Flo que no tenga Alice? Un vocabulario compartido con el cocinero impaciente. No solo es ms fcil la comunicacin con el cocinero, sino que le hace recordar menos cosas pues l tiene todos los patrones del restaurant en su cabeza.Los patrones de diseo nos dan un vocabulario compartido con otros desarrolladores. Una vez que tengamos el vocabulario podemos comunicarnos ms fcilmente con otros desarrolladores e inspirar a otros que no los conocen a aprenderlos. Tambin eleva nuestro pensamiento arquitectnico dejndonos pensar al nivel de patrn, y no a nivel de objeto

Acabo de crear una clase Broadcast. Mantiene el rastro de todos los objetos escuchndolos y en cualquier momento que os datos lleguen les manda un mensaje a todos los que lo escuchan. Lo mejor de todo es que se pueden registrar en cualquier momento ellos mismos es muy dinmico

Rick, por qu no dices solamente que ests utilizando el patrn ObserverExactamente. Si te comunicas en patrones, entonces otros desarrolladores sabrn inmediata y precisamente el diseo que estas describiendo.EjercicioPuedes pensar en vocabularios que sean usados en otros lugares?Que cualidades son comunicadas?Que cualidades se comunican junto a los nombres de los patrones?Que cualidades se comunican cuando decimos patrn strategy?El poder de un vocabulario compartidoCuando nos comunicamos utilizando patrones, hacemos ms que solamente compartir un LINGO.Vocabularios compartidos de patrones son PODEROSOS. Cuando nos comunicamos con otros desarrolladores o nuestro equipo utilizando patrones, estamos comunicando no solo el nombre del patrn sino un conjunto de cualidades, caractersticas y restricciones que esos patrones representan.Utilizamos el patrn Strategy para implementar los varios comportamientos de nuestros patos esto nos dice que los comportamientos del pato han sido encapsulados en sus propio grupos de clases que puedes ser fcilmente expandidos y cambiados, inclusive en tiempo de ejecucin si es necesario.Los patrones nos permiten decir ms con menos. Cuando utilizamos un patrn en una descripcin, otros desarrolladores rpidamente conocen precisamente el diseo que tenemos en menteHablar al nivel de patrones nos permite quedarnos en el diseo ms tiempo. Hablar de sistemas de software utilizando patrones nos permite mantener la discusin a nivel de diseo, sin tener que bajarnos al nivel de detalles de implementacin de objetos y clasesCuntas reuniones o discusiones de diseo hemos atendido que se degradan rpidamente en detalles de implementacin?Vocabularios compartidos pueden turbo cargar al equipo de desarrollo. Un equipo bien educado en patrones de diseo puede moverse ms rpidamente con menos rea para el malentendidoVocabularios compartidos alienta a los desarrolladores junior a actualizarse. Los desarrolladores junior buscan a los experimentados. Cuando los senior utilizan patrones de diseo, los junior se motivan a aprenderlos. Se recomienda construir una comunidad de usuarios de patrones en la organizacin o centro educativoCuando nuestro equipo comienza a compartir ideas de diseo y experiencias en trminos de patrones, se construye una comunidad de usuarios de patronesPensemos en empezar un grupo de estudio de patrones en nuestra organizacin, a veces hasta podemos obtener paga por aprender ;)Cmo puedo usar los patrones de diseo?Todos usamos frameworks como .Net o Java API. Los tomamos y escribimos cdigo a su API, compilamos y creamos programas aprovechando el cdigo que alguien ms ha escrito. Libreras y Frameworks van junto al modelo de desarrollo donde podemos escoger y usar componentes y enchufarlos directamente. Pero no nos ayudan a estructurar nuestras aplicaciones para que sean ms fciles de entender, mantener y al mismo tiempo flexiblesPatrones de diseo no van directamente en el cdigo, sino en tu cabeza, y una vez familiarizado con ellos podremos aplicarlos en nuestros nuevos o antiguos diseos

Nuestro CEREBRONuestro cdigo, ahora nuevo y mejorado con patrones de diseoUn montn de patronesSi los patrones son tan grandiosos, por qu alguien no construye una librera de ellos para no hacerlo yo?Los patrones de diseo estn en un nivel ms alto que las libreras.Los patrones de diseo nos dice cmo estructurar clases y a objetos para resolver ciertos problemas y es nuestro trabajo adaptar esos diseos para que encajen en nuestra aplicacin en particularLas libreras y frameworks no son tambin patrones de diseo?Frameworks y libreras nos son patrones de diseo; proveen implementaciones especficas que nosotros vinculamos a nuestro cdigo. A veces, sin embargo, las libreras y frameworks utilizan patrones de diseo en sus implementaciones. Y eso es grandioso, pues una vez que entendemos los patrones de diseo, entenderemos ms rpidamente los APIs que se han estructurado desde estos patronesEntonces, no existen libreras de patrones de diseo?No, pero aprenderemos despus acerca de catlogos de patrones con listas de patrones que podemos aplicar a nuestra aplicacinPatrones no son ms que la utilizacin de principios de diseo OO

Un error muy comn, Saltamontes, pero es ms sutil que eso. Tienes mucho que aprenderDesarrollador Escptico Gur amistosa de patronesDesarrollador: Ok, hmm, pero no es todo esto acerca del buen diseo OO; o sea que mientras yo siga el encapsulamiento y conozca sobre abstraccin, herencia y polimorfismo, no necesito pensar en patrones de diseo? No es ms sencillo de lo que parece? no es por eso que he recibido todas esas clases de OO? Pienso que los patrones son tiles para las personas que no conocen el buen diseo OO.Gur: Ah, este es uno de los verdaderos malentendidos del desarrollo OO: que al conocer lo bsico de OO automticamente vamos a construir sistemas, flexibles, reutilizables y mantenibles.Desarrollador: Y No es as?Gur: No. Como veremos, construir sistemas OO que tengan estas propiedades no es tan obvio y se descubren solamente con trabajo duro.Desarrollador: Pienso que ya lo entiendo. Estas maneras, a veces no tan obvias, de construir sistemas OO han sido recolectadasGur: s, en un grupo de patrones llamados Patrones de Diseo.Desarrollador: entonces, conociendo patrones, puedo saltarme el trabajo duro e ir directamente a diseos que ya funcionan?Gur: s, hasta cierto punto, pero recuerda, el diseo es un arte. Siempre habrn un precios que pagar. Pero, si sigues patrones ya comprobados, estars bastante adelantado.Desarrollador: Qu puedo hacer si no encuentro un patrn? Gur: Existen algunos principios de diseo que respaldan a los patrones, y conociendo estas te ayudarn a replantear tu diseo cuando no encuentres un patrn que solucione tu problema.Desarrollador: Principios? Adems de Abstraccin, encapsulamiento yGur: S, uno de los secretos de crear sistemas OO mantenibles es pensar cmo pueden cambiar en el futuro y estos principios solucionan estos problemas.

Recuerda, conocer conceptos como abstraccin, herencia y polimorfismo no te hace un diseador orientado a objetos. Un gur en diseo piensa en como crear diseos flexibles que sean fciles de mantener y que puedan evolucionar con los cambiosOO BsicoAbstraccinEncapsulamientoPolimorfismoHerencia

Principios OOEncapsular lo que varaPreferir composicin sobre herenciaProgramar a una interfaz, no una implementacin

Patrones OOStrategy define una familia de algoritmos, encapsula cada uno de ellos, y los hace intercambiables. Strategy deja que los algoritmos varen independientemente de los clientes que los utilizanSumarioConocer lo bsico de OO no te hace un buen diseador OOLos buenos diseos OO son reusables, extensibles y manteniblesPatrones te ensean a crear sistemas con buenas cualidades de diseo OOPatrones son Experiencias comprobadas OOPatrones no te dan cdigo sino soluciones generales a problemas de diseoSumarioNo fueron inventados, fueron descubiertosPatrones y principios administran el problema del cambio en el softwarePatrones permiten que partes de un sistema varen independientemente de otrasBuscamos tomar lo que varia en un sistema y lo encapsulamosPatrones provee un lenguaje compartido