2.

DISEÑO ORIENTADO A OBJETOS

El diseño Orientado a Objetos (DOO) difiere considerablemente del diseño estructurado ya que en DOO no se analiza
un problema en términos de tareas (subrutinas) ni en términos de datos, sino que se analiza el problema como un sis-
tema de objetos que interactúan entre sí.
Un problema desarrollado con técnicas orientadas a objetos requiere, en primer lugar saber cuáles son los objetos del
programa. Como tales objetos son instancias de clases, la primera etapa en el desarrollo orientado a objetos requiere
de la identificación de dichas clases (atributos y comportamiento), así como las relaciones entre éstas y su posterior
implementación en un lenguaje de programación.
Aunque no siempre están bien delimitadas las etapas de análisis y diseño en la OO, se pueden sintetizar de alguna
forma las ideas claves de las distintas tecnologías existentes dentro del desarrollo orientado a objetos al que denomina-
remos diseño.
En el diseño orientado a objetos, los objetos necesitan interactuar y comunicarse, para realizar dicha comunicación, los
objetos utilizan su propia interfaz pública, dicha interfaz se compone principalmente de métodos y propiedades.
El diseño orientado a objetos transforma el modelo del análisis en un modelo de diseño que sirve como anteproyecto
para la construcción de software.
Características principales del Diseño Orientado a Objetos:
• Los objetos son abstracciones del mundo real o entidades del sistema que se administran entre ellas mismas.
• Los objetos son independientes y encapsulan el estado y la representación de información.
• La funcionalidad del sistema se expresa en términos de servicios de los objetos.
• Las áreas de datos compartidas son eliminadas. Los objetos se comunican mediante paso de parámetros.
• Los objetos pueden estar distribuidos y pueden ejecutarse en forma secuencial o en paralelo
Ventajas del Diseño Orientado a Objetos:
• Fácil de mantener, los objetos representan entidades auto-contenidas
• Los objetos son componentes reutilizables
• Para algunos sistemas, puede haber un mapeo obvio entre las entidades del mundo real y los objetos del siste-
ma
Componentes del Diseño Orientado a Objetos
• La identificación de objetos, sus atributos y servicios
• La organización de objetos dentro de una jerarquía
• La construcción de descripciones dinámicas de objetos que muestran como se usan los
• servicios
• La especificación de interfaces de objetos

2.1 MODELOS DEL DISEÑO ORIENTADO A OBJETOS

El modelo del diseño puede verse en dos dimensiones distintas, como se ilustra en la figura 1. La dimensión del proce-
so indica la evolución del modelo del diseño conforme se ejecutan las tareas de éste como parte del proceso del soft-
ware. La dimensión de la abstracción representa el nivel de detalle a medida que cada elemento del modelo de análisis
se transforma en un equivalente de diseño y luego se mejora en forma iterativa.
En la figura 1, la línea punteada indica la frontera entre los modelos de análisis y de diseño. En ciertos casos, es posi-
ble hacer una distinción clara entre ambos modelos. En otros, el modelo de análisis se mezcla poco a poco con el de
diseño y la distinción es menos obvia.
Los modelos del diseño pueden ser estáticos y dinámicos.
• Estáticos: estructura de subsistemas y/o clases, y sus relaciones. Se describe la estructura estática (de datos),
de los objetos del sistema (identidad, atributos y operaciones) y también sus relaciones. El modelo de objetos
contiene diagramas de objetos. Un diagrama de objetos es un grafo cuyos nodos son clases de objetos y cuyos
arcos son relaciones entre las clases. El diagrama contiene clases de objetos organizados en jerarquías que
comparten una estructura y comportamiento comunes y que están asociadas a otras clases. Estas clases defi-
nen los atributos que lleva cada instancia de objeto y las operaciones que efectúa o sufre cada uno. En cada
instancia de la clase se guardan los valores de esos atributos.

1 de 8
 • Dinámicos: Se describen las estructuras que muestran la interacción entre objetos. Ejemplos de UML: dia-
gramas de secuencia, diagramas de estado. Describe los aspectos de comportamiento (de control) de un siste-
ma que cambian con el tiempo. El modelo dinámico se utiliza para especificar e implementar los aspectos del
control del sistema. Los modelos dinámicos contienen diagramas de estados. Un diagrama de estados es un
grafo cuyos nodos son estados y cuyos arcos son transiciones entre estados causadas por sucesos o eventos. Se
especifican en este modelo la temporización y secuencia de operaciones (sucesos que marcan los cambios, se-
cuencias de sucesos, estados que definen el contexto para los sucesos), y la organización de sucesos y de esta-
dos. El modelo dinámico captura el control, aquel aspecto de un sistema que describe las secuencias de opera-
ciones que se producen sin tener en cuenta lo que hagan las operaciones, aquello a lo que afecten o la forma en
la que estén implementadas. Las acciones de los diagramas de estado se corresponden con funciones proce-
dentes del modelo funcional; los sucesos de un diagrama de estado pasan a ser operaciones que se aplican a
objetos dentro del modelo de objetos.

Figura 1. Las dimensión del modelo de diseño

DIAGRAMAS DE ESTADOS.
Los diagramas de estado son una técnica conocida para describir el comportamiento de un sistema. Describen todos
los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como
resultado de los eventos que llegan a él. En la mayor parte de las técnicas Orientadas a Objetos, los diagramas de esta-
do se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida.
Dentro de la notación se utilizan los siguientes símbolos:

2 de 8
De los cuales los más utilizados son:
• Estado. Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna
operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un
rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para
el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al en-
trar, salir o estar en un estado (entry, exit o do, respectivamente).
• Eventos. Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia
puede ser una de varias cosas:
o Condición que toma el valor de verdadero o falso
o Recepción de una señal de otro objeto en el modelo
o Recepción de un mensaje
o Paso de cierto período de tiempo, después de entrar al estado o de cierta hora y fecha particular
El nombre de un evento tiene alcance dentro del paquete en el cual está definido, no es local a la clase que lo
nombre.
• Envío de mensajes. Además de mostrar la transición de estados por medio de eventos, puede representarse el
momento en el cual se envían mensajes a otros objetos. Esto se realiza mediante una línea punteada dirigida al
diagrama de estados del objeto receptor del mensaje.
• Transición simple. Una transición simple es una relación entre dos estados que indica que un objeto en el
primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si cier-
tas condiciones son satisfechas. Se representa como una línea sólida entre dos estados, que puede venir acom-
pañada de un texto con el siguiente formato:
event-signature "[" guard-condition] "/" action-expression "^"send-clause
event-signature es la descripción del evento que da lugar la transición, guard-condition son las condiciones adi-
cionales al evento necesarias para que la transición ocurra, action-expression es un mensaje al objeto o a otro ob-
jeto que se ejecuta como resultado de la transición y el cambio de estado y send-clause son acciones adicionales
que se ejecutan con el cambio de estado, por ejemplo, el envío de eventos a otros paquetes o clases.
• Transición interna. Es una transición que permanece en el mismo estado, en vez de involucrar dos estados
distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el
compartimiento de acciones del estado.
• Acciones. Podemos especificar la solicitud de un servicio a otro objeto como consecuencia de la transición. Se
puede especificar el ejecutar una acción como consecuencia de entrar, salir, estar en un estado, o por la ocu-
rrencia de un evento.
• Generalización de Estados:
o Podemos reducir la complejidad de estos diagramas usando la generalización de estados.
o Distinguimos así entre superestado y subestados.
o Un estado puede contener varios subestados disjuntos.
o Los subestados heredan las variables de estado y las transiciones externas.
o La agregación de estados es la composición de un estado a partir de varios estados independientes.
La composición es concurrente por lo que el objeto estará en alguno de los estados de cada uno de los subes-
tados concurrentes. La destrucción de un objeto es efectiva cuando el flujo de control del autómata alcanza un
estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el
fin del objeto.
• Subestados. Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel
superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conecta-
dos a las entradas y salidas del nivel inmediatamente superior.
• Transición Compleja. Una transición compleja relaciona tres o más estados en una transición de múltiples
fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincroniza-
ción. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado.
• Transición a estados anidados. Una transición hacia un estado complejo (descrito mediante estados anida-
dos) significa la entrada al estado inicial del subdiagrama. Las transiciones que salen del estado complejo se
entienden como transiciones desde cada uno de los subestados hacia afuera (a cualquier nivel de profundidad).
• Transiciones temporizadas
o Las esperas son actividades que tienen asociada cierta duración.
o La actividad de espera se interrumpe cuando el evento esperado tiene lugar.

3 de 8
 • Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flu-
jo de control se transmite entonces a otro estado.

En el siguiente ejemplo se muestra un diagrama de estados de UML para un pedido del sistema de procesos de pedi-
dos. El diagrama indica los diversos estados de un pedido.
Comenzaremos en el punto de partida y mostramos una transición inicial al estado de Comprobación. Esta transición
esta etiquetada como “obtener el primer artículo”. La sintaxis de una etiqueta de transición tiene tres partes, las cuales
son optativas: Evento [Guard guardia] Acción. En este caso solo tenemos la acción “obtiene primer artículo” Una vez
realizada tal acción, entramos al estado de comprobación. Este estado tiene una actividad asociada con él, la cual se
indica mediante una etiqueta con la sintaxis hace/actividad. En este caso, la actividad se llama “comprueba articulo”.

Nótese que se utilizan los términos “acción” para indicar la transición, y “actividad” para indicar el estado. Aunque
son procesos, implementados característicamente mediante algún método sobre Pedido, se tratan de manera diferente.
Las acciones se asocian con las transiciones y se consideran como procesos que suceden con rapidez y no son inte-
rrumpibles. Las actividades se asocian con los estados y pueden tardar más. Una actividad puede ser interrumpida por
algún evento.
Adviértase que la definición de “rápidamente” depende del tipo de sistema que se está produciendo. En un sistema de
tiempo real, “rápidamente” puede significar unas pocas líneas de código de máquina; en los sistemas de información
normales, “rápidamente” puede significar menos de unos cuantos segundos.
Cuando una transición no tiene evento alguno en su etiqueta, significa que la transición se da tan pronto como se com-
pleta cualquier actividad asociada con el estado dado. En este caso, ello significa tan pronto termine la Comprobación.
Del estado Comprobación se derivan tres transiciones. Las tres solo tienen guardias en su etiqueta. Un guardia es una
condición lógica que solo devuelve “verdadero” o “falso” Una transición de guardia ocurre solo si el guardia se re-
suelve como “verdadero”.
Solo se puede tomar una transición de un estado dato, por lo que tratamos de que los guardias sean mutuamente exclu-
yentes para cualquier evento. En la figura 1 abarcamos tres condiciones:
1. Si no hemos comprobado todos los artículos, tomamos el siguiente artículo y regresamos al estado de com-
probación para comprobarlo.
2. Si hemos comprobado todos los artículos y todos están en existencia, hacemos la transición al estado de Des-
pachando.
3. Si hemos comprobado todos los artículos pero no todos están en existencia, hacemos la transición al estado
espera.
Veamos, en primer lugar, el estado Espera. Como no hay actividades para este estado, el pedido se detiene en el espe-
rando un evento, ambas transiciones del estado espera se etiquetan con el evento Articulo recibido. Esto significa que
el pedido espera hasta que detecta este evento. Llegado ese momento, evalúa los guardias de las transiciones y hace la
transición apropiada.
4 de 8
Dentro del estado despachando, tenemos actividad que inicia una entrega. También hay una transición simple no
guardada, disparada por el evento Entregado. Esto significa que la transición ocurrirá siempre que tenga lugar el even-
to. Sin embargo, nótese que la transición no sucede cuando termina la actividad; por el contrario, una vez terminada la
actividad “iniciar entrega”, el pedido se mantiene en el estado Despachando, hasta que ocurre el evento Entregado
La última cuestión a considerar es la transición denominada “cancelado”. Queremos tener la posibilidad de cancelar
un pedido en cualquier momento, antes de que sea entregado. Podríamos hacerlo dibujando transiciones separadas
desde cada uno de los estados, Comprobación, Espera y Despachando. Una alternativa útil es crear un Superestado
con los tres estados, y después dibujar una transición simple, a partir de él. Los subestados simplemente heredan todas
las transiciones sobre el superestado.

5 de 8
2.2 PROCESOS DEL DISEÑO ORIENTADO A OBJETOS
El diseño de software es un proceso iterativo por medio del cual se traducen los requerimientos en un “plano” para
construir el software. Al principio, el plano ilustra una visión holística del software. Es decir, el diseño se representa
en un nivel alto de abstracción, en el que se rastrea directamente el objetivo específico del sistema y los requerimien-
tos más detallados de datos, funcionamiento y comportamiento. A medida que tienen lugar las iteraciones del diseño,
las mejoras posteriores conducen a niveles menores de abstracción.

Lineamientos y atributos de la calidad del software.

El diseño es importante porque permite que un equipo de software evalúe la calidad de éste antes de que se implemen-
te, momento en el que es fácil y barato corregir errores, omisiones o inconsistencias.
Durante el diseño, la calidad se evalúa por medio de la realización de una serie de revisiones técnicas. Una revisión
técnica es una reunión celebrada por miembros del equipo de software. Por lo general, participan dos, tres o cuatro
personas, en función del alcance de la información del diseño que se revisará.
Lineamientos para el diseño:
1. Debe tener una arquitectura que a) se haya creado con el empleo de estilos o patrones arquitectónicos recono-
cibles, b) esté compuesta de componentes con buenas características de diseño y c) se implementen en forma
evolutiva de modo que faciliten la implementación y las pruebas.
2. Debe ser modular, es decir, el software debe estar dividido de manera lógica en elementos o subsistemas.
3. Debe contener distintas representaciones de datos, arquitectura, interfaces y componentes.
4. Debe conducir a estructuras de datos apropiadas para las clases que se van a implementar y que surjan de pa-
trones reconocibles de datos.
5. Debe llevar a componentes que tengan características funcionales independientes.
6. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambien-
te externo.
7. Debe obtenerse con el empleo de un método repetible motivado por la información obtenida durante el análi-
sis de los requerimientos del software.
8. Debe representarse con una notación que comunique con eficacia su significado.

2.3 PATRONES DE DISEÑO ORIENTADO A OBJETOS

Los patrones de diseño (design patterns) son soluciones habituales a problemas comunes en el diseño de software.
Cada patrón es como un plano que se puede personalizar para resolver un problema de diseño particular.
Los patrones de diseño son unas técnicas para resolver problemas comunes en el desarrollo de software y otros ámbi-
tos referentes al diseño de interacción o interfaces. Son soluciones simples y elegantes a problemas específicos y co-
munes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Un patrón es una descripción del problema y la esencia de su solución, que se puede reutilizar en casos distintos.
Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber
comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable,
lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Los patrones de diseño expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir
sistemas de software.
Está claro que un equipo de desarrollo no se limita a aplicar los principios del diseño orientado a objetos una vez tras otra, lo
más seguro es que se aprovechen de las soluciones aplicadas en el pasado para resolver los problemas del presente.
La solución a algunos problemas del desarrollo viene en forma de bloques de código y de esqueletos de una solución,
a estos bloques de código se les conoce como patrones.
Podríamos definir un patrón de la siguiente manera:
“Un patrón describe un problema que ocurre de forma iterativa en nuestro entorno, también describe la solu-
ción a dicho problema de tal forma que podemos usar la misma solución todas las veces que sea necesario”.

Tipos de patrones
• Estructurales
• De creación
• De comportamiento
Los patrones de diseño son un conjunto de prácticas de óptimo diseño que se utilizan para abordar problemas recu-
rrentes en la programación orientada a objetos.

Objetivos de los patrones

Los patrones de diseño pretenden:
• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
6 de 8
 • Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño.

Elementos de un patrón
En general, un patrón tiene cuatro elementos esenciales:
1. El nombre del patrón: permite describir en una o dos palabras, un problema de diseño junto con sus soluciones
y consecuencias.
2. El Problema describe cuando aplicar el patrón. Explica el problema y su contexto. A veces el problema inclu-
ye una serie de condiciones que deben darse para que tenga sentido aplicar el patrón.
3. La Solución describe los elementos que constituyen el diseño, sus relaciones, responsabilidades y colabora-
ciones. La solución no describe un diseño o implementación en concreto, sino que un patrón es más bien co-
mo una plantilla que puede aplicarse en muchas situaciones diferentes.
4. Las Consecuencias son los resultados así como las ventajas e inconvenientes de aplicar el patrón. Estas son
fundamentales para evaluar las alternativas de diseño y conocer los costos y beneficios de aplicar el patrón.

Uso de patrones en el diseño

Los patrones de diseño pueden usarse aplicando mecanismos diferentes: herencia y composición. La composición de
objetos debe ser favorecida por encima de la herencia cuando existen ambas opciones. Antes de crear grandes e inma-
nejables jerarquías de clases (la consecuencia del sobreuso de la herencia), la composición favorece pequeñas jerarqu-
ías de clases y objetos que permanecen centrados en un objetivo. La composición usa patrones de diseño existentes de
forma inalterada.
En ingeniería de software, disponemos de 3 familias de patrones:
• Patrones de diseño
• Patrones de arquitectura
• Patrones de refactorización
Para trabajar con patrones de diseño debemos identificar el problema y aplicar el patrón que nos da la solución, nunca
debemos aplicarlos a un problema cuya descripción no coincide exactamente con la definición del patrón.
Un patrón de diseño puede considerarse como un documento que define una estructura de clases que aborda una situa-
ción particular. Los patrones de diseño se dividen en tres grupos principales:
1. Patrones de creación
2. Patrones estructurales
3. Patrones funcionales:

Patrones de creación
Los patrones de creación proporcionan ayuda a la hora de crear objetos, principalmente cuando esta creación requiere
tomar decisiones. La toma de decisiones utilizando patrones puede ser dinámica. Estos patrones ayudan a estructurar y
encapsular estas decisiones. En algunas ocasiones existe más de un patrón que se puede aplicar a la misma situación.
En otras ocasiones se pueden combinar múltiples patrones convenientemente.
Algunos de los patrones de creación más utilizados son: Patrón de Fábrica Abstracta, Patrón Constructor, Patrón del
Método de Fabricación, Patrón Prototipo, Patrón de Instancia Única (Singleton).

Patrones estructurales
Los patrones estructurales describen como los objetos y las clases pueden ser combinados para formar estructuras más
grandes, es decir, proporcionan los mecanismos para este hecho. La diferencia entre el modelo de clases y el modelo
de objetos es que las clases desarrollan la abstracción con la ayuda de la herencia y como estos pueden ser más utiliza-
dos para proporcionar más utilidad al programa de interfaz. Por otro lado los patrones estructurales describen como los
objetos pueden ser asociados y combinados para formar estructuras más grandes y más complejas.
Algunos de los patrones estructurales más utilizados son los siguientes: Patrón Adaptador, Patrón Puente, Patrón
Compuesto, Patrón Decorador, Patrón de Fachada, Patrón de Peso Mosca, Patrón Apoderado.

Patrones funcionales
Los patrones funcionales tratan específicamente la comunicación entre los objetos.

7 de 8
Algunos de los patrones de creación más utilizados son: Patrón de Cadena de Responsabilidad, Patrón de Comando,
Patrón Intérprete, Patrón Iterador, Patrón Mediador, Patrón Memento, Patrón Observador, Patrón de Estado, Patrón de
Estrategia, Patrón del Método Plantilla, Patrón Visitante.

¿Cómo se describe un patrón de diseño?

• Describe las clases que se requieren para implementar la solución
• Se describen las clases responsables de la construcción de un objeto y su comportamiento.
• Lineamientos que conduzcan a una implementación efectiva por el programador.
• Se describen ejemplos de código fuente.
• El programador deberá observar cada oportunidad en la que puedan reutilizarse patrones ya existentes en vez
de crear otros.

2.4 ESTRUCTURAS
Una estructura no es un patrón arquitectónico, sino un esqueleto con varios puntos de conexión que permiten adaptarlo a
un dominio de problema específico. Los puntos de conexión permiten integrar clases o funciones específicas de un pro-
blema dentro del esqueleto. En un contexto orientado a objetos, una estructura es un conjunto de clases que cooperan.
Diferencias entre patrones de diseño y estructuras:
1. Los patrones de diseño son más abstractos que las estructuras. Las estructuras están incrustadas en el código,
pero en éste solo es posible incrustar ejemplos de patrones. Una ventaja de las estructuras es que se escriben
en lenguajes de programación y no sólo son estudiadas, sino ejecutadas y reutilizadas directamente.
2. Los patrones de diseño son elementos arquitectónicos más pequeños que las estructuras. Una estructura nor-
mal contiene varios patrones de diseño, pero lo contrario nunca se cumple.
3. Los patrones de diseño están menos especializados que las estructuras. Las estructuras siempre tienen un do-
minio particular de aplicación. En contraste, los patrones de diseño se usan en casi cualquier tipo de aplica-
ción. Si bien es posible tener patrones de diseño más especializados, incluso éstos no imponen la arquitectura
de una aplicación.

2.5 Estructuras o plantillas de patrones

Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y
puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en
esta área han propuesto plantillas ligeramente distintas. Si bien la mayoría definen los mismos conceptos básicos.
La plantilla más común es la utilizada por el GoF 1 y consta de los siguientes apartados:
• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se
expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
• Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
• Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
• Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
• Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
• Código de ejemplo: Código fuente ejemplo de implementación del patrón.
• Usos conocidos: Ejemplos de sistemas reales que usan el patrón.

1
GoF: es la abreviatura de Gang of Four (Pandilla de Cuatro), nombre con que se conoce a Erich Gamma, Richard Helm, Ralph
Johnson y John Vlissides autores del libro "Patrones de diseño: Elementos de software orientado a objetos reutilizables", biblio-
grafía fundamental para aprender a usar patrones de diseño.
8 de 8