IGF115

Ingeniera de
Software

PATRONES Y
ANTIPATRONES

2012

Contenido
Introduccin. ................................................................................................................................3
Objetivos. .....................................................................................................................................4
General:....................................................................................................................................4
Especficos: ...............................................................................................................................4
Patrones y Anti patrones. .............................................................................................................5
Patrones de Software. ..............................................................................................................5
Caractersticas de un buen patrn. ..........................................................................................5
Nivel de Patrones. ....................................................................................................................7
Patrones de Diseo. .............................................................................................................7
Describir los patrones de diseo. .........................................................................................8
Clasificacin de los patrones de diseo. .............................................................................10
Catalogo de Patrones. ........................................................................................................12
Cmo los Patrones de Diseo resuelven problemas de diseo. ........................................14
Cmo seleccionar un patrn de diseo ..............................................................................19
Cmo utilizar un patrn de diseo .....................................................................................21
Antipatrones de Software ......................................................................................................22
Transformacin formal de Refactorizacin ............................................................................23
Tipos de antipatrones.............................................................................................................23
Ejemplo del antipatron BLOD .................................................................................................26
Forma general. ...................................................................................................................26
Sntomas y consecuencias ..................................................................................................27
Causas tpicas .....................................................................................................................27
Solucin refactorizada. .......................................................................................................28
Conclusin. .................................................................................................................................31

Introduccin.
Como elemento de un lenguaje, un patrn es una instruccin que muestra como puede ser
usada esta configuracin espacial una y otra vez para resolver el sistema de fuerzas, siempre
que el contexto lo haga relevante.
Para comenzar, intentaremos establecer una definicin bsica del concepto de patrn. De la
misma forma que sucede con otros conceptos de la informtica (y como es el caso de la
arquitectura), no es fcil establecer una definicin taxativa y definitiva del concepto de patrn.
Pero intentaremos reunir a las ms influyentes y significativas que nos permitan comprender la
idea y establecer las bases para nuestro estudio, mencionando la taxonoma de los patrones,
los cuales describen una estructura recurrente de componentes que se comunican para
resolver un problema general de diseo en un contexto particular.
Adems hablaremos de los Anti patrones que son soluciones negativas que presentan ms
problemas que los que solucionan.
As pues enfocndonos en los Patrones Anti-patrones de Diseo, y as poder mostrar las
ventajas y desventajas inherente a su aplicacin en el desarrollo, refinando subsistemas o
componentes de software orientado a objetos.

Objetivos.
General:
Conocer la definicin de patrn y anti-patrn en la Ingeniera de Software y como la
utilizacin de estos influyen positiva o negativamente en el desarrollo de los sistemas
de informacin o software en general, y as evaluar el contexto en el cual nos ayudan a
facilitar una solucin de sistemas.

Especficos:
Conocer los conceptos de patrones y anti-patrones.

Identificar la taxonoma de los niveles de patrones y anti-patrones existentes.

Profundizar en los conceptos y utilizacin de patrones y anti-patrones de diseo.

Patrones y Anti patrones.

Patrones de Software.
Si bien la teora original de los patrones aplica a la construccin de casas y
planeamiento urbanstico, tambin puede ser aplicada al software. Los patrones de
software facilitan la reutilizacin del diseo y de la arquitectura, capturando las
estructuras estticas y dinmicas de colaboracin de soluciones exitosas a problemas
que surgen al construir aplicaciones.
De la misma forma que hemos buscado una definicin para el concepto general de
patrones en la literatura existente, haremos lo propio con los patrones de software.
Una definicin de este tipo de patrones que goza de amplia aceptacin en la
comunidad del software es la dada por Richard Gabriel en A Timeles Way of Hacking.
Cada patrn es una regla de 3 partes, que expresa una relacin entre un contexto, un
sistema de fuerzas que ocurren repetidamente en ese contexto y una configuracin de
software que permite que se resuelvan esa fuerzas.
Otra definicin complementaria, ms enfocada en el mbito tcnico, es la que se da en
el libro de Microsoft Enterprise Development Reference Architecture:
Una descripcin de un problema recurrente que ocurre en un contexto determinado
y, basada en un conjunto de fuerzas, recomienda una solucin. La solucin es
usualmente un mecanismo simple: una colaboracin entre dos o ms clases, objetos,
servicios, procesos, threads, componentes o nodos que trabajan juntos para resolver el
problema identificado por el patrn.
Finalmente, citamos la frase con que comienza el libro Pattern Oriented Software
Architecture , Volume 1:
Los patrones le ayudan a construir sobre la experiencia colectiva de ingenieros de
software experimentados. Estos capturan la experiencia existente y que ha
demostrado ser exitosa en el desarrollo de software, y ayudan a promover las buenas
prcticas de diseo. Cada patrn aborda un problema especfico y recurrente en el
diseo o implementacin de un sistema de software.

Caractersticas de un buen patrn.

1. Resuelve un problema: Los patrones capturan soluciones, no principios o
estrategias abstractas.
2. Es un concepto probado: Capturan soluciones, no teoras o especulaciones. En
el caso del Design Patterns, el criterio para decidir si algo era un patrn o no,
era que ste deba tener al menos 3 implementaciones reales.

3. La solucin no es obvia: Muchas tcnicas de resolucin de problemas (como

los paradigmas o mtodos de diseo de software) intentan derivar soluciones
desde principios bsicos. Los mejores patrones generan una solucin a un
problema indirectamente (un enfoque necesario para los problemas de diseo
ms difciles).
4. Describe una relacin: Los patrones no describen mdulos sino estructuras y
mecanismos.
5. Tiene un componente humano significante: El software sirve a las personas.
Los mejores patrones aplican a la esttica y a las utilidades (de hecho, no es
casual que varios de los primeros lenguajes de patrones tengan que ver con
temas estticos y utilidades como Hot Draw ET++).
Pattern Happy
El trmino Patterns Happy es un calificativo aplicable a los programadores que se
refiere al uso indiscriminado de patrones, an cuando su utilizacin no agrega ningn
valor a la solucin que se est desarrollando. Un programador Pattern Happy aprende
un patrn e inmediatamente encuentra un lugar para abusar de l. Para dejar claro
se tomo un breve prrafo de Refactoring to Patterns donde se define este calificativo
de la siguiente forma:
Has aprendido alguna vez algn patrn de software y quisiste usarlo en ese mismo
momento, porque te gust? Mucho? Entonces eres un amante de los patrones. Los
patrones no son siempre la solucin adecuada o mejor para un problema. Si bien
aaden flexibilidad, tambin aaden complejidad. Es por esto que se debe ser
cuidadoso al momento de seleccionar patrones. Siempre hay que recordar que los
patrones son un punto de partida y que no son dogmas incuestionables. El uso
indiscriminado de patrones, an en situaciones donde no aportan ningn beneficio,
puede ser un antipatrn o un claro indicador de ser un Pattern Happy (esto es
alguien que abusa de los patrones sin razn).

Nivel de Patrones.
Segn el libro Pattern Oriented Software Architecture, Volume 1 se definen los
siguientes niveles.

Es importante destacar que esta divisin no es absoluta ni totalmente comprehensiva,

dado que no incluye a otros patrones de amplia aceptacin y utilizacin como los de
anlisis, integracin de aplicaciones, pruebas, etc.
En este documento nos enfocaremos en los patrones de diseo.
Patrones de Diseo.

"Cada patrn describe un problema que se produce una y otra vez en nuestro medio, y
luego describe el ncleo de la solucin a ese problema, de tal manera que se puede
utilizar esta solucin un milln de veces, sin tener que hacerlo de la misma manera dos
veces".
En general, el patrn tiene cuatro elementos esenciales:
1. El nombre del modelo es un manipulador que podemos utilizar para describir
un problema de diseo, su soluciones y consecuencias en una o dos palabras. Nombrar
un patrn inmediatamente aumenta nuestro vocabulario de diseo. Esto nos permite
disear a un nivel ms alto de abstraccin. Tener un vocabulario de patrones nos
permite hablar de ellos con nuestros colegas, en nuestra documentacin, e incluso a
nosotros mismos. Se hace ms fcil pensar en diseos y comunicar a ellos ya sus
compensaciones a los dems. Encontrar un buen nombre ha sido una de las partes ms
difciles de desarrollar nuestro catlogo.
2. El problema se describe cundo se aplica el patrn. En l se explica el problema
y su contexto. Podra describir los problemas especficos de diseo tales como la forma
para representar algoritmos como objetos. Podra describir la clase de objeto o
estructuras que son sintomticos de un diseo inflexible. A veces, el problema incluir

una lista de condiciones que deben cumplirse antes de que tenga sentido aplicar el
patrn.
3. En La solucin se describen los elementos que componen el diseo, sus
relaciones, responsabilidades y colaboraciones. La solucin no describe un diseo
particular de aplicacin, porque un patrn es como una plantilla que puede ser
aplicado en muchas situaciones diferentes. En su lugar, el patrn proporciona una
descripcin abstracta de un problema de diseo y cmo una disposicin general de los
elementos (clases y objetos en nuestro caso).
4. Las consecuencias son los resultados y compensaciones de la aplicacin del
modelo.Aunque las consecuencias son a menudo sorda cuando describimos las
decisiones de diseo,que son fundamentales para la evaluacin de alternativas de
diseo y para la comprensin de los costes y beneficios de aplicar el patrn. Dado que
la reutilizacin es a menudo un factor endiseo orientado a objetos, las consecuencias
de un patrn incluyen su impactoen la flexibilidad de un sistema, extensibilidad, o la
portabilidad. Aadir estasconsecuencias explcitamente ayuda a entenderlos y
evaluarlos.
Describir los patrones de diseo.

Cmo describir los patrones de diseo? Si bien son importantes y tiles, no son
suficientes. Ellos simplemente capturan el producto final del proceso de diseo como
las relaciones entre clases y objetos. Para reutilizar el diseo, tambin se debe
registrar las decisiones, alternativas y compensaciones que condujo a ella. Ejemplos
concretos son importantes, porque ayudan a ver el diseo en accin.
Se describen los patrones de diseo utilizando un formato consistente. Cada patrn se
divide en secciones de acuerdo con la siguiente plantilla. La plantilla le da una
estructura uniforme de la informacin, por lo que los patrones de diseo son ms
fciles de aprender, comparar, y usar.

Nombre del Patrn.

El nombre del patrn transmite la esencia del patrn sucintamente. Un buen nombre
es vital, porque se convertir en parte del vocabulario de diseo.
Intencin.
Una breve declaracin que contesta a las siguientes preguntas: Qu significa el patrn
de diseo? Cul es su razn de ser y la intencin? Qu particular diseo asunto o
problema resolver?
Tambin conocido como?
Otros nombres conocidos para el patrn, si los hubiere.

Motivacin.
Un escenario que ilustra un problema de diseo y cmo la clase y el objeto en el
patrn de resuelven el problema. El escenario ayudar a comprender la descripcin
ms abstracta del patrn que sigue.
Aplicabilidad.
Cules son las situaciones en las que se puede aplicar el patrn de diseo?
Cules son ejemplos pobres de diseos que el patrn puede tratar? Cmo
puedereconocer estas situaciones?
Estructura.
Una representacin grfica de las clases en el patrn de uso de una notacin sobre la
base de la tcnica de modelado de objetos. Tambin se puede utilizar diagramas de
interaccin para ilustrar secuencias de peticiones y la colaboracin entre los objetos.
Los participantes.
Las clases y / o objetos que participan en el patrn de diseo y su responsabilidades.
Colaboraciones.
Cmo los participantes colaboran para llevar a cabo sus responsabilidades.
Consecuencias.
Cmo el patrn apoya sus objetivos? Cules son las ventajas y desventajas y
resultados de usar el patrn? Qu aspecto de la estructura del sistema lo hacen variar
de forma independiente?

Implementacin.
Qu tcnicas se deben tener en cuenta al implementar el patrn? Existen problemas
especficos de lenguaje?
Ejemplo de cdigo.
Fragmentos de cdigo que muestran cmo se puede implementar el modelo en el
lenguaje de programacin que se utiliza.
Usos conocidos.
Ejemplos del patrn que se encuentra en los sistemas reales. Se incluye al menos dos
ejemplos de diferentes dominios.

Patrones Relacionados.
Qu patrones de diseo estn estrechamente relacionados con ste? Cules son las
diferencias importantes? Con qu otros patrones deben ser utilizados?
Clasificacin de los patrones de diseo.
mbito abstracto.
Proporcionar una interfaz para crear familias de asociadas o dependientes objetos sin
especificar sus clases concretas.
Adaptador.
Convertir la interfaz de una clase en otra interfaz que el cliente espera.
El adaptador permite a las clasestrabajar juntas que podan debido a interfaces incompatibles.
Puente.
Desacoplar una abstraccin de su implementacin, de manera que los dos puedan variar de
forma independiente.
Constructor.
Separar la construccin de un objeto complejo de su representacin de modo que el mismo
proceso de construccin puede crear diferentes representaciones.
Cadena de responsabilidad.
Evitar el acoplamiento del remitente de una solicitud a su receptor, dando a ms de un objeto
la oportunidad de manejar la peticin. Cadena de objetos que reciben y pasan la solicitud a lo
largo de la cadena hasta que un objeto la maneje.

Comando.
Encapsular una peticin como un objeto, lo que le permite parametrizar clientes con
diferentes peticiones, solicitudes o registros de la cola, y el apoyo deshacer operaciones.
Compuesto.
Componer objetos en estructuras de rbol para representar parte-todo jerarquas. Un patrn
compuesto permite a los clientes tratar objetos individuales y composiciones de objetos de
manera uniforme.
Decorador.

10

Fijar responsabilidades adicionales a un objeto dinmicamente. Estos patronesproporcionan

una alternativa flexible para crear subclases para extender la funcionalidad.
Fachada.
Proporcionar una interfaz unificada para un conjunto de interfaces de un subsistema. La
fachada define una interfaz de alto nivel que hace que el subsistema ms fcil de usar.
Mtodo de fbrica.
Define una interfaz para crear un objeto, pero vamos a decidir subclases qu clase instanciar.
El mtodo de fbrica permite aplazar una clase de instancias de subclases.
Peso mosca.
Utilizar uso compartido para apoyar a un gran nmero de objetos de grano fino
eficientemente.
Intrprete.
Dado un lenguaje, define una representacin para su gramtica junto con un intrprete que
utiliza la representacin de interpretar frases en el idioma.
Iterator.
Proporciona una forma de acceder a los elementos de un objeto agregado secuencialmente sin
exponer su representacin subyacente.
Mediador.
Define un objeto que encapsula como un conjunto de objetos interactan.
Mediador promueve la articulacin flexible por objetos de mantenimiento de referirse a cada
otra manera explcita, y que le permite variar su interaccin de forma independiente.
Memento.
Sin violar la encapsulacin, captura y exteriorizar un objeto de estado interno de modo que el
objeto puede ser restaurado a este estado despus.
Observador.
Definir una dependencia de uno a muchos entre los objetos de manera que cuando un
objetocambios de estado, todos sus dependientes son notificados y actualizados
automticamente.
Prototipo.
Especifica los tipos de objetos a crear utilizando una instancia prototpica,y crear nuevos
objetos copiando este prototipo.
Proxy.

11

Proporcionar un sustituto o marcador de posicin de otro objeto para controlar el accesoa la

misma.
Singleton.
Asegurar una clase slo tiene una instancia y proporcionar un punto global de acceder a la
misma.
Estado.
Permita que un objeto modifique su comportamiento cuando cambia su estado interno.
El objeto aparecer para cambiar su clase.
Estrategia.
Define una familia de algoritmos, encapsula cada uno, y los hacerintercambiables. Esta
estrategia permite al algoritmo variar independientemente de los clientes que lo utilizan.
Mtodo plantilla.
Definir el esqueleto de un algoritmo en una operacin, difiriendo algunospasos a subclases.
Mtodo plantilla permite a las subclases redefinir ciertos pasos de un algoritmo sin cambiar la
estructura del algoritmo.
Visitantes.
Representa una operacin a realizar sobre los elementos de un objetoestructura. Visitantes le
permite definir una nueva operacin sin cambiar las clases de los elementos en los que opera.

Catalogo de Patrones.
Los patrones de diseo varan en su granularidad y nivel de abstraccin. Debido a que hay
muchos patrones de diseo, necesitamos una forma de organizarlos. En esta seccin se
clasifica patrones de diseo de manera que podemos hacer referencia a familias de patrones
relacionados. La clasificacin le ayuda a aprender los patrones del catlogo ms rpido, y
puede que dirigir los esfuerzos para encontrar nuevos patrones tambin.
Clasificamos a los patrones de diseo de dos criterios. El primer criterio, llamado efecto, que
refleja lo que un patrn hace. Los patrones pueden tener ya sea creacional,finalidad
estructural o de comportamiento. Patrones creacionales se refieren al proceso de creacin de
objetos. Patrones estructurales tratan con la composicin de las clases o objetos. Patrones de
comportamiento caracterizar las formas en que las clases u objetos interactuar y distribuir la
responsabilidad.

12

Clase

mbito de
Aplicacin

Objeto

Propsito.
Creacional
Estructural
Mtodo de
Adaptador
fbrica
mbito Abstracto
Adaptador
Constructor
Puente
Prototipo
Composite
Singleton
Decorador
Fachada
Peso Mosca
Proxy

Comportamiento
Interpretador
Mtodo plantilla
Cadena de
responsabilidad
Comando
Iterator
Mediador
Memento
Observador
Estado
Estrategia
Visitante

El segundo criterio, llamado mbito de aplicacin, especifica si el patrn se aplica

principalmente a las clases o a los objetos. Patrones de clase frente a las relaciones
entre clases y sus subclases. Estas relaciones se establecen a travs de la herencia,
para que estn esttico-fijos en tiempo de compilacin. Patrones de objetos frente a
las relaciones de objeto, que se puede cambiar en tiempo de ejecucin y son ms
dinmicas. Casi todos los patrones usan la herencia hasta cierto punto. As que los
nicos patrones etiqueta "clase patrones"son aquellos que se centran en las relaciones
de clase.
Hay otras maneras de organizar los patrones. Algunos patrones se utilizan a menudo
juntos. Por ejemplo, el compuesto se utiliza a menudo con Iterator o Visitante. Algunos
patrones son alternativas: Prototype es a menudo una alternativa al mbito abstracto.
Algunos patrones resultan en diseos similares a pesar de que los patrones tienen
intenciones diferentes. Por ejemplo, los diagramas de estructura de Composite y
Decorator son similares. Sin embargo, otra manera de organizar los patrones de diseo
es de acuerdo a la forma en que se referencian unos a otros en sus "patrones
relacionados".

13

Cmo los Patrones de Diseo resuelven problemas de diseo.

Aqu estn varios de estos problemas y cmo los patrones de diseo resuelven
problemas.
Bsqueda de objetos apropiados
Programas orientados a objetos se componen de objetos. Un paquete de objetos,
datosy procedimientos ambos operan sobre esos datos. Los procedimientos se
denominan tpicamentemtodos u operaciones. Un objeto realiza una operacin
cuando se recibe una solicitud(O mensaje) desde un cliente.

14

Las peticiones son la nica forma de obtener un objeto para ejecutar una operacin.
Operaciones son la nica manera de cambiar los datos internos de un objeto. Debido a
estas restricciones,estado interno del objeto se dice que est encapsulado, no se
puede accederdirectamente, y su representacin es invisible desde el exterior del
objeto.
La parte difcil de diseo orientado a objetos es descomponer un sistema en objetos.
La tarea es difcil porque muchos factores entran en juego: la
encapsulacin,granularidad, la dependencia, la flexibilidad, el rendimiento, la
evolucin, la reutilizacin, ysigue. Todos ellos influyen en la descomposicin, a
menudo de maneras opuestas.Metodologas de diseo orientado a objetos estn a
favor de muchos enfoques diferentes. Se puedeescribir una declaracin del problema,
sealar a los sustantivos y verbos, y crear correspondienteclases y operaciones. O se
puede centrar en las colaboraciones y responsabilidadesen su sistema. O se puede
modelar el mundo real y traducir los objetos encontradosdurante el anlisis en el
diseo. Siempre habr desacuerdo sobre cul es el mejor enfoque.
Muchos objetos en un diseo provienen del modelo de anlisis. Pero diseos
orientados a objetos a menudo terminan con clases que no tienen equivalentes en el
mundo real. Algunos deestas son las clases de bajo nivel como arrays. Otros son
mucho ms alto nivel. Por ejemplo,el compuesto presenta un patrn de abstraccin
para el tratamiento de los objetosuniformemente que no tiene una contraparte fsica.
Modelado estricto del mundo real conduce a un sistema que refleja la realidad de hoy,
pero no necesariamentede maana. Las abstracciones que surgen durante el diseo
son la clave para hacer un diseoflexible.
Los patrones de diseo ayudan a identificar menos abstracciones obvias y los objetos
quepuede capturar. Por ejemplo, los objetos que representan un proceso o algoritmo
noocurren en la naturaleza, sin embargo, son una parte crucial de diseos flexibles. La
Estrategia patrn describe cmo implementar familias intercambiables de algoritmos.
El Estado patrn representa cada estado de una entidad como un objeto. Estos objetos
son raramente encontrados durante el anlisis o incluso las primeras etapas de diseo.
Determinando objeto Granularidad
Los objetos pueden variar enormemente en tamao y nmero. Pueden representar
todohacia abajo en el hardware o todo el camino hasta aplicaciones completas. Cmo
decidimoslo que debera ser un objeto?
Los patrones de diseo frente a este problema tambin. La Fachada (patrn
describecmo representar subsistemas completos como objetos, y el patrn de peso

15

mosca describe cmo apoyar a un gran nmero de objetos en los mejores

granularidades.
Otros patrones de diseo describen formas especficas de descomponer un objeto en
partes ms pequeas objetos. mbito Abstracto y Constructor Produccin de objetos
cuyas nicasresponsabilidades estn la creacin de otros objetos. Visitantes y
Comando rendimientoobjetos cuyas responsabilidades son slo para ejecutar una
solicitud en otro objetoo grupo de objetos.
Especificacin de interfaces de objetos
Cada operacin declarada un objeto especifico al nombre de la operacin, los
objetosque toma como parmetros, y el valor de la operacin de retorno. Esto se
conoce como laoperacin de la firma. El conjunto de todas las firmas definidas por las
operaciones de un objetose llama interfaz para el objeto. Interfaz de un objeto que
caracterizaun conjunto completo de peticiones que pueden ser enviadas al objeto.
Cualquier solicitud que coincide conuna firma en la interfaz del objeto puede ser
enviado al objeto.Un tipo es un nombre usado para referirse a una interfaz particular.
Hablamos de un objetocomo tener el tipo "Ventana" si acepta todas las solicitudes de
las operaciones definidasen la interfaz denominada "Ventana". Un objeto puede tener
muchos tipos, y muy diferentesobjetos pueden compartir un tipo. Parte de la interfaz
de un objeto se puede caracterizar porun tipo, y otras partes de otros tipos. Dos
objetos del mismo tipo, slo necesitacompartir parte de sus interfaces. Las interfaces
pueden contener otras interfaces como subconjuntos.
Decimos que un tipo es un subtipo de otro si su interfaz contiene la interfazde su
supertipo. A menudo se habla de un subtipo hereda la interfaz de susupertipo.
Las interfaces son fundamentales en sistemas orientados a objetos. Los objetos se
conocen sloa travs de sus interfaces. No hay forma de saber nada acerca de un
objeto opara pedirle que haga algo sin tener que pasar a travs de su interfaz. Un
objeto de la interfazno dice nada acerca de sus diferentes objetos de aplicacin son
libres de aplicarsolicitudes de manera diferente. Eso significa que tiene dos objetos
completamente diferentesimplementaciones pueden tener interfaces idnticas.
Cuando se enva una solicitud a un objeto, la operacin particular que se
realizadepende tanto de la solicitud y el objeto receptor. Diferentes objetos
quesolicitanapoyo idntico pueden tener diferentes implementaciones de las
operacionesque cumplan con estos requerimientos. La asociacin de tiempo de
ejecucin de una peticin a un objetoy una de sus operaciones se conoce como enlace
dinmico.

16

Especificacin de implementaciones de objetos

Hasta ahora hemos dicho poco sobre la forma en que realmente definen un objeto. De
un objetoaplicacin se define por su clase. La clase especifica interno del objetolos
datos y la representacin y define las operaciones que el objeto puede realizar.
Rectngulo con negrita, Operaciones aparecen en letra normal por debajo de la
clasenombre. Cualquier dato que define la clase viene despus de las operaciones.
Lneas separadasel nombre de la clase de las operaciones y las operaciones de los
datos:

Tipos de valor devueltos y tipos de variables de instancia son opcionales, ya que no

asumen unaesttica de tipos de lenguaje de implementacin.
Los objetos son creados por instancias de una clase. El objeto se dice que es una
instanciade la clase. El proceso de crear instancias de una clase de almacenamiento
asigna para los datos internos de objeto (formado por las variables de instancia) y
asocia lasoperaciones con estos datos. Muchos casos similares de un objeto pueden
ser creadoscreando una instancia de una clase.
Una punta de flecha de lnea discontinua indica una clase que crea instancias de
objetos de otraclase. La flecha apunta a la clase de los objetos instanciados.

Nuevas clases pueden ser definidas en trminos de clases existentes mediante la

herencia de clases.
Cuando una subclase hereda de una clase padre, se incluyen las definiciones de
todoslos datos y las operaciones que define la clase padre. Los objetos que son
instanciasde la subclase contendrn todos los datos definidos por la subclase y sus
clases de padres,y van a ser capaces de realizar todas las operaciones definidas por la
presente subclase y suspadres. Se indica la relacin subclase con una lnea vertical y un
tringulo:

17

Una clase abstracta es aquella cuyo principal propsito es definir una interfaz comn
parasus subclases. Una clase abstracta difiere parte o la totalidad de su
implementacina las operaciones definidas en las subclases, por lo que una clase
abstracta no puede ser instanciada.
Las operaciones que declara una clase abstracta pero no implementa son
llamadasoperaciones abstractas. Las clases que no son abstractas se llaman clases
concretas.
Las subclases pueden refinar y redefinir los comportamientos de sus clases para
padres. Msespecficamente, una clase puede anular una operacin definida por su
clase principal.
Anulacin de las subclases da la oportunidad de manejar las peticiones en lugar de su
padreclases. La herencia de clases permite definir clases simplemente mediante la
ampliacin de otras clases, por lo que es fcil de definir familias de objetos que tienen
una funcionalidad relacionada.
Los nombres de las clases abstractas aparecen en tipo inclinado para distinguirlos de
lasclases concretas. Tipo inclinado tambin se utiliza para denotar operaciones
abstractas. El diagrama puede incluir pseudocdigo para la ejecucin de una
operacin, si es as, el cdigoaparecer en una caja de perro de orejas conectadas por
una lnea de puntos para que el funcionamientoimplementos.

18

Una clase mixin es una clase que est destinado a proporcionar una interfaz opcional
ofuncionalidad a otras clases. Es similar a una clase abstracta en que esno pretende ser
una instancia. Clases Mixin requieren herencia mltiple:

Cmo seleccionar un patrn de diseo

Con ms de 20 patrones de diseo para elegir, puede ser difcilencontrar el que trate
un problema de diseo particular, especialmente si elcatlogo es nuevo y desconocido.
Aqu hay varios enfoques diferentes paraencontrar el patrn de diseo que se adapte a
su problema:
1. Considere cmo los patrones de diseo resuelven problemas de diseo. Cmo los
patrones de diseo ayudan a encontrar objetos adecuados, determinar
objetogranularidad, especificar interfaces de objetos, y varias otras formas en las que
los patrones de diseo resuelven problemas de diseo. Refirindose a estas
discusiones puedeayudar a orientar su bsqueda por el patrn correcto.
2. Escanear secciones intencin. Se enumeran las secciones de Intencintodos los
patrones en el catlogo. Leer a travs de la intencin de cada patrn para
encontraruno o ms que sonar relevante para su problema.
3. Estudiar cmo los patrones se interrelacionan. El estudio de estas relaciones puede
ayudar adirigir al patrn correcto o grupo de patrones.
4. Estudiar los patrones de igual propsito. El catlogo tiene tres clasificaciones,uno
para los patrones creacionales, otro para los patrones estructurales, y un tercerolos
patrones de comportamiento.
5. Examinar la causa de rediseo. Mira las causas de rediseo para ver si el problema
est relacionado con uno o ms de ellos. Luego, buscar enlos patrones que ayudan a
evitar las causas de rediseo.
6. Considerar lo que debe ser variable en el diseo. Este enfoque es elopuesto de
centrarse en las causas de rediseo. En lugar de considerar lo quepodra forzar un
cambio en el diseo, considerar lo que se quiere ser capaz de cambiarsin redisear.

19

PROPOSITO
Creacional

PATRON DE DISEO
mbito Abstracto
Constructor
Mtodo de Fabrica

Estructural

Prototipo
Singleton
Adaptador
Puente
Compuesto
Decorador
Fachada
Flyweight
Proxy

Comportamiento Cadena de Responsabilidad

Comando
Interpretador
Iterator
Mediador
Memento

Observador

Estado
Estrategia
Mtodo de Plantilla
Visitante

ASPECTO(S) QUE PUEDE VARIAR

Familias de objetos de productos.
Cmo un objeto compuesto se
crea.
Subclase de objeto que es
instanciado.
Clase de objeto que es instanciado.
La nica instancia de una clase.
Interfaz a un objeto.
Implementacin de un objeto.
La estructura y la composicin de
un objeto.
Responsabilidades de un objeto sin
Subclases.
Interfaz a un subsistema.
Gastos de almacenamiento de
objetos.
Cmo se accede a un objeto, su
ubicacin.
Objeto que puede satisfacer una
solicitud.
Cundo y cmo se cumple una
solicitud.
Gramtica e interpretacin de un
idioma.
Como se accede a los elementos
agregados, recorridos.
Como y cuales objetos interactan
entre s.
Qu informacin privada se
almacena fuera de un objeto, y
cuando.
Nmero de objetos que dependen
de otro objeto, cmo los objetos
dependientes estn al da.
Estado de un objeto.
Un algoritmo.
Pasos de un algoritmo.
Las operaciones que se pueden
aplicar al objeto (s) sin cambiar su
clase (s).

20

Cmo utilizar un patrn de diseo

Una vez elegido un patrn de diseo, cmo usarlo? Aqu hay un paso a pasopara la
aplicacin de un modelo de diseo de forma eficaz:
1. Leer el patrn de una vez a travs de una visin general. Prestar especial atencin a
las secciones de aplicabilidad y Consecuencias para garantizar si el modelo es
adecuado para el problema.
2. Volver atrs y estudiar las secciones de estructura, los Participantes y
Colaboraciones.Asegrese de entender las clases y los objetos del modelo y cmo se
relacionan entre s.
3. Mira la seccin de cdigo para ver un ejemplo concreto de la pauta en el cdigo.
Estudiar el cdigo ayuda a aprender cmo implementar el patrn.
4. Para seleccionar nombres de los participantes de patrones que son significativos en
el contexto de la aplicacin. Los nombres de los participantes en los patrones de
diseo son generalmente demasiado abstracto para aparecer directamente en una
aplicacin. Sin embargo, es til incorporar el nombre del participante en el nombre
que aparece en la solicitud. Esto ayuda a hacer el modelo ms explcito en la
aplicacin.
Por ejemplo, si se utiliza el patrn de estrategia para un algoritmo de composicin de
texto, entonces podra tenerse clases SimpleLayoutStrategy o TeXLayoutStrategy.
5. Definir las clases. Declarar las interfaces, establecer relaciones de herencia, y definir
las variables de instancia que representan los datos y referencias a objetos. Identificar
las clases existentes en la aplicacin que el patrn se afecta, y modificar en
consecuencia.
6. Definir aplicacin de los nombres especficos para las operaciones en el patrn. Aqu
de nuevo, los nombres generalmente dependen de la aplicacin. Utilizar las
responsabilidades y colaboraciones asociadas a cada operacin como gua. Adems,
ser coherente en las convenciones de nomenclatura. Por ejemplo, puede utilizar la
funcin "Create-" como prefijo para indicar consistentemente un mtodo de fbrica.
7. Implementar las operaciones para llevar a cabo las responsabilidades y
colaboraciones en el patrn. Estas son slo directrices para ayudar a empezar. Con el
tiempo desarrollar una manera propia de trabajar con patrones de diseo.
Ninguna discusin sobre cmo utilizar patrones de diseo no estara completa sin unas
palabras sobre cmo no hay que usarlos. Los patrones de diseo no deben aplicarse
indiscriminadamente.

21

A menudo, lograr flexibilidad y variabilidad mediante la introduccin de niveles

adicionales de indireccin, y eso puede complicar el diseo y/o costar algo de
rendimiento.

Antipatrones de Software
Los antipatrones podran definirse como una herramienta para solucionar los
problemas por el mal uso de los patrones, es decir abusar de un patrn lo hace un
antipatron.
Los antipatrones sirven para dos propsitos importantes:

Ayudar a identificar el problema

Y ayudar a implementar la solucin.

Al disear un patrn se puede crear un antipatron cuando este causa ms problemas

que soluciones, todos los patrones tienen consecuencias.
Hay situaciones donde un patrn es una buena solucin para un problema pero en
otras situaciones este se vuelve un antipatron, en ocasiones un antipatron provee
beneficios en ciertas situaciones, depende del contexto.
Antipatron: es literalmente una forma de describir una solucin a un problema que
genera consecuencias negativas. El antipatron puede ser el resultado de la
administracin o desarrollo de algo no muy bien conocido, es decir, no tener
experiencia o conocimiento suficiente para solucionar un tipo de problema en
particular, como aplicar perfectamente un buen patrn en un contexto equivocado.
Los antipatrones proveen experiencia del mundo real en el reconocimiento de
problemas en la industria de software, por lo cual ofrece herramientas para reconocer
los problemas y determinar las causas de este y como solucionarlo.
Realmente los antipatrones definen una migracin o refactorizacin de soluciones
negativas a soluciones positivas.
Donde la refactorizacin se define como una tcnica de la ingeniera de software para
reestructurar un cdigo fuente, alterando su estructura interna sin cambiar su
comportamiento externo, es decir, que no arregla errores ni aade funcionalidad. El
objetivo, por el contrario, es mejorar la facilidad de comprensin del cdigo o cambiar
su estructura y diseo y eliminar cdigo muerto, para facilitar el mantenimiento en el
futuro.

22

Hay varias observaciones importantes que ayudarn en su labor futura en

patrones y antipatrones:

Los patrones de diseo comienzan con una solucin recurrente: los patrones de
diseo son escritos de abajo hacia arriba, mas adelante el autor del patrn de
diseo aade contexto y fuerza. El contexto y la fuerza son cuidadosamente
elaboradas para conducir a una nica solucin.
Los antipatrones comienza con un problema recurrente: los antipatrones se
escriben de arriba hacia abajo. Las descripciones de los antipatrones incluye
aprender de los elementos, como sus sntomas, consecuencias y causas.
Usar grupos de estudio: es til discutir sobre una descripcin escrita del
antipatron y su solucin a refactorizar en un entorno de grupo.
Convertirse en un autor de antipatron: un nuevo autor de antipatrones puede
enfocarse en problemas recurrentes que son observados desde distintos
contextos(al menos 3).

Transformacin formal de Refactorizacin

Un objetivo clave en el desarrollo de antipatrones es describir de una forma til para la
refactorizacin de software.
La transformacin formal de refactorizacin incluye:

Abstraccin de superclase. Se aplica a dos o ms clases similares. Una

abstraccin superclase crea una clase abstracta que emerge de la
implementacin comn
de varias clases concretas.
Eliminacin condicional. La refactorizacin se aplica cuando la estructura y
comportamiento de una clase depende en gran medida de una sentencia
condicional.
Abstraccin total. Reorganiza las relaciones entre las clases para mejorar su
estructura y extensibilidad.

Tipos de antipatrones

BLOD
Estilo de procedimiento de diseo que dirige a un objeto con responsabilidades
compartidas, mientras la mayora de otros objetos tienen datos y ejecutan
procesos simples. La solucin incluye refactorizacin de diseo para distribuir
las responsabilidades ms uniformemente y aislar el efecto de los cambios.

23

CONTINUOUS OBSOLESCENCE(OBSOLOCENCIA CONTINUA)

La tecnologa est cambiando tan rpidamente que los desarrolladores
frecuentemente tienen problemas para mantenerse al da con las versiones
actuales de software y encontrar combinaciones de lanzamientos de productos
que trabajen juntos. Teniendo en cuenta que cada lnea de producto comercial
evoluciona a travs de nuevos lanzamientos, esta situacin es cada vez ms
difcil para los desarrolladores. Encontrar lanzamientos de productos
compatibles que interoperan con xito es cada vez ms difcil.

LAVA FLOW(FLUJO DE LAVA)

Cdigo muerto y la informacin de diseo olvidado est congelado en un
constante cambio de diseo. Esto es anlogo al flujo de lava con glbulos de
endurecimiento de materiales rocosos.la solucin refactorizada incluye un
proceso de gestin de la configuracin que elimine el cdigo muerto y
evolucione o sea refactorizado el diseo para aumentar la calidad.

AMBIGUOUS VIEWPOINT(PUNTO DE VISTA AMBIGUO)

El modelo de anlisis y diseo orientado a objetos (OOA&D), es presentado
frecuentemente sin puntos de vista claros que representen el modelo. Por
defecto este modelo denota un punto de vista de implementacin que es
potencialmente menos til.la mezcla de puntos de vista no permita la
separacin fundamental de interfaces de la implementacin de detalles, que es
uno de los principales beneficios del paradigma orientado a objetos.

FUNCTIONAL DECOMPOSITION(DESCOMPOSICION FUNCIONAL)

Este antipatron es la salida de experiencia, no orientado a objetos de los
desarrolladores quienes disean e implementan una aplicacin en un lenguaje
orientado a objetos. El cdigo resultante se asemeja a un lenguaje estructural
(Pascal, FORTRAN) en la estructura de clases. Puede ser increblemente
complejo como un desarrollador inteligente procesales disean muy
inteligentemente maneras para replicar sus mtodos probados en el tiempo en
una arquitectura orientada a objetos.

POLTERGEISTS(DUENDES)
Son clases con muchos roles limitados y ciclos de vida efectivos.
Frecuentemente comienzan procesos de otros objetos. La solucin
refactorizada incluye una reasignacin de de responsabilidades a los objetos de
larga vida para que eliminen los poltergeists.

24

BOAT ANCHOR
Es una pieza del software o del hardware que no sirve para un propsito til en
un proyecto actual. Frecuentemente este antipatron hace ms costosa su
adquisicin, hace irnica la compra de la pieza que se necesita.

GOLDEN HAMMER(MARTILLO DE ORO)

Es una tecnologa familiar o concepto aplicado obsesivamente a muchos
problemas de software. La solucin implica expandir el conocimiento de los
desarrolladores a travs de grupos de estudio en educacin, formacin y libros
para exponer a los desarrolladores tecnologas alternativas y enfoques.

DEAD END
Se logra modificando un componente reutilizable, si el componente modificado
ya no es mantenido y el proveedor no da soporte de este. Cuando estas
modificaciones son hechas, se transfieren la carga de soporte a los
desarrolladores y a los de mantenimiento de sistemas de aplicacin. Las
mejoras que se hacen en los componentes reutilizables no se integran
fcilmente, y los problemas de soporte pueden ser adjudicados a la
modificacin.

SPAGHETTI CODE
La estructura de software hace ms difcil extender y optimizar el cdigo. Con
frecuencia el refactorizado del cdigo puede mejorar la estructura del
software, soporte del mantenimiento de este y permitir el desarrollo iterativo.

INPUT KLUDGE
Software que con pruebas de comportamiento no sencillas, puede ser un
ejemplo de este antipatron, las cuales ocurren cuando algunos algoritmos son
empleados para la manipulacin de programas de entrada.

WALKING THROUGH A MINEFIELD(CAMINANDO POR UN CAMPO DE MINAS)

Se puede encontrar numerosos errores en productos de software, expertos
estiman que el cdigo fuente original contiene de 2 a 5 errores por lnea de
cdigo.

CUTANDPASTE PROGRAMMING
Reutilizar cdigo para copiar recursos de instrucciones que conducen a
problemas de mantenimiento significativos. Una forma alternativa de
reutilizacin, incluida la reutilizacin de la caja negra reduciendo los problemas
de mantenimiento para tener cdigo fuente comn, pruebas y documentacin.

25

MUSHROOM MANAGEMENT
En algunas arquitecturas y crculos de gestin, hay una poltica explicita para
mantener a los desarrolladores de sistemas aislados de los usuarios finales del
sistema. Los requerimientos son pasados por segundas manos a travs de
intermediarios, como pueden ser arquitectos, gerentes o analistas de
requerimientos.

Ejemplo del antipatron BLOD

Nombre del antipatron: El Blob.
Escala ms frecuente: Aplicacin.
Nombre de la solucin refactorizado: refactorizacin de responsabilidades.
Tipo de la solucin refactorizado: Software.
Causas principales: pereza y prisa.
Fuerzas desbalanceadas: gestin de funcionalidad, rendimiento y complejidad.
Ancdota evidente: esta la clase es realmente el corazn de nuestra arquitectura
Forma general.

Este antipatron consiste en disear donde una clase monopoliza los procesos, y otras
clases que primeramente encapsule los datos, utiliza notacin de objetos y la
implementacin de lenguajes orientados a objetos. Se caracteriza por un diagrama de
clases compuesto de una sola clase compleja controladora rodeada de clases de datos
simples, como se muestra en la figura siguiente:

26

El blob es un diseo procedimental, contiene la mayora de los procesos y otros

objetos que contienen los datos, este antipatron puede ser resultado de la asignacin
inapropiada de requerimientos. Por ejemplo puede ser un modulo que se le da
responsabilidades que superpones otras partes del sistema.
Sntomas y consecuencias

Una clase con un gran nmero de atributos, de operaciones o de ambos. Como

que una clase contenga 60 o ms atributos y operaciones, lo cual indica la
presencia del blob.
Una sola clase controladora con asociacin simple, clases de objetos de datos.
La clase blob es tpicamente compleja para reutilizar y realizar pruebas, que
puede hacerla ineficiente o introducir complejidad excesiva para reutiliza el
blob para subconjuntos de de su funcionalidad.
La clase blob tambin puede gastar mucha memoria al cargarse, usando
recursos excesivos con cada operacin simple.

Causas tpicas

Falta de una arquitectura orientada a objetos. Puede ser que los diseadores
no posean una buena compresin de los principios orientados a objetos.
Demasiada intervencin limitada. Al desarrollar a travs de iteraciones, los
desarrolladores tienden a aadir pequeas funcionalidades a clases ya
existentes, en vez de vez de crear nuevas clases para no cargar mucho a una

27

sola clase, por lo que sera bueno revisar la jerarqua para la asignacin de
responsabilidades entre las clases.
Solucin refactorizada.

Pasos a seguir:
1. Identificar o categorizar los atributos y operaciones de acuerdo a los contratos.
Los contratos deben ser cohesivos en que todos se relacionan con un objetivo
comn, comportamiento o funcin dentro del sistema global.

Librera Blob.

Reagrupando el Blob por contratos.

2. Buscar el lugar adecuado de estas colecciones (datos u operaciones) en

contratos de funcionalidad y despus migrar all. Como se muestra en la
siguiente imagen, que de la clase Library se emigran a la clase Catalog las
operaciones relacionadas a los catlogos:

28

3. Eliminar las asociaciones redundantes, siguiendo el ejemplo, la clase Item

estaba asociada a unos elementos de la clase Library que ahora pertenecen a la
clase Catalog, con lo cual hay asociaciones redundantes.
4. Migrar las asociaciones de la clase derivada a una clase base comn. Despus
de quitar las asociaciones redundantes entre Library e Item, se migran los
elementos de Catalog a la clase Item, es decir se crea una asociacin entre
ellos.

29

5. Por ltimo, se eliminan todas las asociaciones transitorias, sustituyendo segn

corresponda cada tipo especificador de atributo y argumentos de operaciones,
de acuerdo con el ejemplo, Check_Out_Item y Search_For_Item serian
procesos transitorios, deberan ser movidos a una clase transitoria separada
con atributos locales.

30

Conclusin.
Dado todo lo anterior podemos concluir que los patrones son un recurso muy til para
guiarnos en la creacin de proyectos de software, pues nos permiten llevar a cabo las
mejores prcticas con mtodos ya probados por otros programadores.
Aun asel abuso en el uso de los patrones o una mala utilizacin de estos puede derivar
en un anti-patrn, lo cual nos complica el trabajo y aumenta la cantidad de recursos a
utilizar para corregir los errores.

31