Paradigma orientado a objetos:

Abstracción:

Se define abstracción como la extracción y análisis de la abundancia de información en datos

relacionados. Es importante que los datos relacionados se mantengan juntos para su fácil manipulación.
Es igualmente importante abstraer la información genérica de la información específica con que se
cuenta.

Análisis sobre qué conoce y sobre qué hace un elemento determinado.

Análisis de las características, atributos y métodos que son (y que no son) de interés para la aplicación
en consideración.

La abstracción de un elemento depende del contexto en el que se define.

Encapsulamiento:

Se define encapsulamiento como el ocultamiento de datos relacionados detrás de una interface de

métodos. Estos métodos permiten acceder a la información y manipularla convenientemente.

Modulariza las características de un elemento.

Un sistema se modulariza en clases, las que se modularizan en métodos y atributos.

El comportamiento es encapsulado en métodos. La información es encapsulada en atributos.

A través del encapsulamiento se define el qué se hace ocultando el cómo se hace.

Ocultamiento de la información:

Restricción de acceso al estado interno de un elemento.

Si una clase requiere información sobre otra clase, entonces debe solicitarla (no debe utilizarla
directamente).

El ocultamiento de la información previene escribir código altamente acoplado.

Componentes:

Un componente es una unidad modular y extensible de implementación independiente que tiene un

contrato especifico de interfaz y dependencias explícitamente definidas.

 MODULARIDAD: posee todo lo necesario para su funcionalidad

 EXTENSIBILIDAD: debiera poder extenderse su funcionalidad original
 ABIERTO: soporte a diferentes plataformas e interacción con otros componentes

Proceso de desarrollo:

Es un conjunto de fases, métodos, técnicas y prácticas que se usan para desarrollar y mantener software
con sus documentos asociados. Puede ser, RAD, basado en componentes, Iterativo, incremental, espiral,
UP, etc.
Frameworks:

Conjunto reutilizable de bloques de construcción de software que se pueden usar, extender o adecuar.

Patrones:

Es una solución reusable de un problema común que soporta la transferencia de técnicas provadas y
desiciones a otros programadores.

Tipos de patrones:

 Patrones de procesos
 Patrones de análisis
 Patrones de diseño

Herencia:

Mecanismo mediante el cual una clase de objetos se define como un caso particular de otra clase de
objetos.

La representación de una relación “es-un” (un auto es un vehículo), “es-como” (un dragón es como un
pájaro) o es “es-tipo-de” (un círculo es un tipo de figura) entre dos clases.

La generalización permite agrupar características comunes entre clases (factorización de características

comunes).

La especialización permite reusar una abstracción existente (clase) para definir una nueva clase más
específica

La herencia simple se presenta cuando una clase hereda de una y solo una clase, mientras que la
herencia múltiple se presenta cuando una clase hereda de más de una clase.

(no todos los lenguajes orientados a objetos soportan herencia múltiple debido a que su gestión es
complicada y raramente se encuentra en el mundo real)

Asociación:

Una asociación es una relación estructural que especifica que objetos de una clase están conectados con
objetos de otra clase (pudiendo ser la segunda la misma que la primera).

Un rol en una asociación es la cara que presenta una clase a la otra clase al otro lado de la asociación.

La multiplicidad de un rol en una asociación especifica cuántos objetos están conectados al otro lado de
la asociación.

Una asociación unidireccional es una asociación que puede ser navegada solo en un solo sentido.

Una asociación bidireccional es una asociación que puede ser navegada en ambos sentidos.

(si no se especifica una dirección es bidireccional)

Agregación:

Una agregación modela una relación “todo-parte” en la que un lado de la relación especifica el
elemento contenedor (“todo”) y el otro lado especifica los contenidos (“partes”).

Una agregación modela una relación “tiene un”.

Composición:

Una relación de composición es una forma fuerte de agregación en la que el contenedor es

completamente responsable de sus contenidos y cada contenido está asociado a uno y solo un
contenedor.

El tiempo de vida de las partes contenidas es coincidente con el tiempo de vida del contenedor.

Polimorfismo:

Mecanismo por el cual un objeto puede responder al mismo mensaje de diferentes maneras,
permitiendo a los objetos interactuar con otros sin conocer su tipo exacto anticipadamente.

Existen dos clases de polimorfismo:

 Polimorfismo real:
o Paramétrico
o De inclusión
 Polimorfismo aparente
o Overloading
o Coerción

Los lenguajes polimórficos son aquellos en los que los elementos pueden tener más de un tipo.

Las funciones (o métodos) polimórficas son aquellas aplicables a valores de más de un tipo.

Los tipos polimórficos son tipos cuyas operaciones son aplicables a operandos de más de un tipo.

Polimorfismo real paramétrico:

El polimorfismo paramétrico se presenta cuando un método tiene un tipo de parámetro explícito o

implícito que determina el tipo de argumento real para cada aplicación del método.

Los métodos con polimorfismo paramétrico son denominados también métodos genéricos.

Pueden trabajar con argumentos de diversos tipos, generalmente realizando el mismo tipo de trabajo
independientemente del tipo de argumento.

Polimorfismo real de inclusión:

El polimorfismo de inclusión se presenta cuando un objeto puede ser visto como perteneciente a
diversos tipos (que no deben ser disjuntos): debe haber inclusión de tipos.

El polimorfismo de inclusión permite el modelado de subtipos y herencia en orientación a objetos.

Polimorfismo aparente: Overloading:

El mismo nombre de variable es usado para denotar distintas funciones utilizándose el contexto para
decidir qué función es aplicable por esa instancia particular.

El overloading podría ser evitado con un preprocesamiento del programa que brinde distintos nombres
a las distintas funciones. En ese sentido es una abreviación sintáctica.

Polimorfismo aparente: Coerción:

La coerción es una operación semántica necesaria para convertir un argumento al tipo esperado por una
función.

Las coerciones pueden ser provistas estáticamente (en forma explícita de código) o dinámicamente (con
test de argumentos en tiempo de ejecución).

Referencia polimórfica:

Una referencia polimórfica es una referencia que puede referir, en el tiempo, a instancias de más de una
clase. Como consecuencia de esto, cada referencia posee un tipo dinámico y otro estático asociado a
ella.

Binding dinámico:

Vinculación del código asociado con un llamado a un método en tiempo de ejecución.

En orientación a objetos el binding dinámico es asociado con el polimorfismo y la herencia en el hecho

que un llamado a un método asociado con una referencia polimórfica puede depender del tipo dinámico
de esa referencia.

Acoplamiento:

El acoplamiento es la medida de cuán interrelacionados están dos elementos entre sí.

Cuando una clase depende de otra se dice que está acoplada.

Cuando una clase interactúa con otra, pero sin conocer sus detalles de implementación, se dice que está
débilmente acoplada.

Cuando una clase se apoya en la implementación de otra se dice que está altamente acoplada.

Cohesión:

La cohesión es el grado de relación existente entre los elementos de un ítem encapsulado (componente
o clase).

Generalmente se intenta definir clases o métodos altamente cohesivos (requerimientos de eficiencia

pueden ser la excepción a la regla)

Una buena medida de la cohesión de un elemento es cuánto toma en describirlo en una oración: cuanto
menos lleva en describirlo más cohesivo es el elemento.
Visibilidad:

Se entiende por Visibilidad a la capacidad de un objeto de “ver” o tener una referencia a otro objeto.

Hay cuatro formas de visibilidad:

 De atributo
 De parámetro
 Local
 Global
Patrón de Diseño:

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el
desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Un patrón de diseño es una solución a un problema de diseño. 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 reusable, lo
que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

¿Qué es un patrón de diseño?

Ante un problema reiterado ofrece una solución contrastada que lo resuelve. Describe el problema en
forma sencilla. Describe el contexto en que ocurre. Describe los pasos a seguir. Describe los puntos
fuertes y débiles de la solución. Describe otros patrones asociados.

¿Por qué usarlos?

Mejora en la comunicación y documentación

 “Hay que hacer un Factory Method”

 Facilita la documentación interna del proyecto.

Mejora la ingeniería de software: Eleva el nivel del grupo de desarrollo.

Previene “reinventar la rueda” en diseño: Son soluciones ya probadas.

Mejora la calidad y estructura: “¿Cuan grande debe ser una clase?”

Categorización:

Fundamentales: Se usan en otros patrones más grandes

Creación: Aislar el proceso de creación de un objeto.

Estructura: Desacopla el sistema.

Comportamiento: Describe situaciones de control de flujo.

Patrón para utilizar según el problema:

Crear un objeto sin especificar la clase a la que pertenece:

 Abstract factory
 Factory Method
 Prototype

Dependencia para tareas específicas:

 Command
 Cadena de responsabilidad

Dependencia hacia el hardware o software:

  Abstract factory
 Bridge

Dependencia hacia los algoritmos:

 Strategy
 Template method
 Builder

Alto acoplamiento:

 Facade
 Mediator
 Observer

Imposibilidad de cambiar las claves convenientemente:

 Adapter
 Decorator
 Visitor

Fundamentos de diseño:

Programar para la interfaz, no para la herencia. Favorecer la composición antes que la herencia.
Delegación. Doble herencia.

Herencia o interfaz:

La herencia de clase define la implementación de una clase a partir de otra (excepto métodos
abstractos)

La herencia de interfaz define como se llamará el método o propiedad, pudiendo escribir distinto código
en cada clase.

Programar para la interfaz:

Permite reducir las dependencias, el cliente desconoce la implementación, la vinculación se realiza en

tiempo de ejecución, y da consistencia (contrato)

Como desventaja tiene su no direccionamiento.

Favorecer la composición:

Ventajas de la herencia: Implementación ya realizada. Útil en situaciones “es un”

Desventajas de usar herencia: Construir un monstruo. No se puede cambiar la implementación

heredada en tiempo de ejecución. Quebrar la encapsulación. Visibilidad.
Ventajas de la composición: Crear una nueva clase ensamblando con más de una clase. Puede cambiar la
clase con la cual ensamblo en tiempo de ejecución. Centrar cada clase en una tarea.

Desventaja de la composición: Requiere escribir un poco más de código. El no direccionamiento.

Delegación:

Una forma de componer. Se delega un conjunto de operaciones de un objeto en otro objeto.

“La herencia” que use en VB6.

Delegado:

En Ingeniería de software, el patrón de diseño de delegación es una técnica en la que un objeto de cara
al exterior expresa cierto comportamiento, pero en realidad delega la responsabilidad de implementar
dicho comportamiento a un objeto asociado en una relación inversa de responsabilidad.

El patrón de diseño de Delegación es la abstracción fundamental que da soporte a la composición

(también referida como agregación).

Definición: La delegación es un mecanismo, usado en la programación orientada a objetos, por medio

de la cual una clase delega en otra una determinada funcionalidad. Se aplica como sustitución a la
herencia. De hecho, es una forma de hacer composición tan potente como ésta. Como valor añadido,
permite, combinado con la herencia múltiple de interfaces, sustituir la herencia múltiple de clases en los
lenguajes donde no se permite ésta última directamente. Además, Los conflictos de nombres que se
plantean en la herencia múltiple se resuelven manualmente con esta técnica.

Diferencias con Herencia: La delegación se caracteriza por "reutilización selectiva", en cambio en

herencia es un "todo o nada". Es cierto que en Composición y delegación se escribe mucho más que en
herencia, ya que en herencia se hereda de forma declarativa, y esto simplifica al programador en ciertos
casos. Se habla de la herencia como Caja Blanca y de Composición y delegación como Caja Negra. Es
conveniente usar herencia cuando la relación de "Es Un" es clara, es obvia.

Delegado en Java: Cuando programamos en Java en muchas ocasiones nos encontramos con la
necesidad de usar el concepto de delegación. Este concepto es muy habitual cuando tenemos
estructuras de clase de composición. Es decir, un objeto A contiene un Objeto B. Por ejemplo,
supongamos que tenemos el diagrama de clases de Coche y Motor. Como podemos ver acceder en
nuestro código a la potencia es un poco enrevesado. Podemos apoyarnos en el concepto de delegación
y generar nuevos métodos a nivel de la clase Coche para que “deleguen” en los de motor y todo sea más
sencillo.
Doble herencia:

Problema: Mantener las clases que implementan como interna del proyecto (internal o Friend), pero la
interfaz pública.

Organizar las clases que tienen un comportamiento parecido para que sea consistente.

La clase base es abstracta, puede heredar de mas de una interfaz y una vez escritos los métodos puedo
verificar si hay duplicación en las clases hijas.

Patrones de diseño:

 Patrones de creación
 Patrones estructurales
 Patrones de comportamiento

Patrones de creación:

Tienen el propósito de separar los procesos de creación de un objeto y de uso de un objeto. Crear un
objeto es una toma de decisión.

Tipos: Factory method, singleton y abstract factory

Factory Method:

Problema: La instancia del objeto a crear depende de condiciones externas a la clase cliente, puede
cambiar independientemente de cambiar la clase cliente. Ya he creado la estructura con “Doble
Herencia”, pero ahora necesito poder crear una instancia de cualquier clase concreta.

Patrones de creación: Factory Method:

El patrón Factory Method permite escribir aplicaciones que son más flexibles respecto de los tipos a
utilizar difiriendo la creación de las instancias en el sistema a subclases que pueden ser extendidas a
medida que evoluciona el sistema. Permite también encapsular el conocimiento referente a la creación
de objetos. Factory Method hace también que el diseño sea más adaptable a cambio de sólo un poco
más de complejidad. Se utiliza frecuentemente con Template Method. En la sección de ejemplos de
código de este patrón presentaremos una implementación de este caso.

Patrones de creación: Singleton:

Problema: No se puede tener mas de una instancia de una clase y se necesita controlar en acceso a una
clase.

El patrón de diseño singleton (instancia única) está diseñado para restringir la creación de objetos
pertenecientes a una clase o el valor de un tipo a un único objeto.

Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de
acceso global a ella.

El patrón singleton se implementa creando en nuestra clase un método que crea una instancia del
objeto sólo si todavía no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente
se regula el alcance del constructor (con atributos como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de ejecución. Si dos
hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe todavía, sólo uno de ellos
debe lograr crear el objeto. La solución clásica para este problema es utilizar exclusión mutua en el
método de creación de la clase que implementa el patrón.

Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha clase controla
el acceso a un recurso físico único (como puede ser el ratón o un archivo abierto en modo exclusivo) o
cuando cierto tipo de datos debe estar disponible para todos los demás objetos de la aplicación.

El patrón singleton provee una única instancia global gracias a que:

La propia clase es responsable de crear la única instancia. Permite el acceso global a dicha instancia
mediante un método de clase. Declara el constructor de clase como privado para que no sea
instanciable directamente.

Abstract factory:

Problema: Necesito crear una familia de objetos, trabajo con mas de una familia, no puedo combinar
ítems de las familias de objetos y el resto del sistema debe trabajar sin distinguir entre familias de
objetos

La estructura típica del patrón Abstract Factory es la siguiente:

Cliente: La clase que llamará a la factoría adecuada ya que necesita crear uno de los objetos que provee
la factoría, es decir, Cliente lo que quiere es obtener una instancia de alguno de los productos
(ProductoA, ProductoB).

AbstractFactory: Es de definición de la interfaces de las factorías. Debe de proveer un método para la

obtención de cada objeto que pueda crear. ("crearProductoA()" y "crearProductoB()")

Factorías Concretas: Estas son las diferentes familias de productos. Provee de la instancia concreta de la
que se encarga de crear. De esta forma podemos tener una factoría que cree los elementos gráficos
para Windows y otra que los cree para Linux, pudiendo poner fácilmente (creando una nueva) otra que
los cree para MacOS, por ejemplo.

Producto abstracto: Definición de las interfaces para la familia de productos genéricos. En el diagrama
son "ProductoA" y "ProductoB". En un ejemplo de interfaces gráficas podrían ser todos los elementos:
Botón, Ventana, Cuadro de Texto, Combo... El cliente trabajará directamente sobre esta interfaz, que
será implementada por los diferentes productos concretos.

Producto concreto: Implementación de los diferentes productos. Podría ser por ejemplo
"BotónWindows" y "BotónLinux". Como ambos implementan "Botón" el cliente no sabrá si está en
Windows o Linux, puesto que trabajará directamente sobre la superclase o interfaz.

Patrones de estructura:

Propósito: Los patrones estructurales están relacionados con cómo las clases y los objetos se combinan
para dar lugar a estructuras más complejas.
Puede hacerse aquí la misma distinción que haciamos en los patrones de creación y hablar de patrones
estructurales asociados a clases (Adapter) y asociados a objetos (Bridge, Composite, Decorator, Facade,
Flyweight, Proxy), los primeros utilizarán la herencia, los segundos la composición.

Los patrones estructurales asociados con objetos describen formas de componer los objetos para
conseguir nueva funcionalidad. La flexibilidad de la composición de objetos viene de la posibilidad de
cambiar la composición en tiempo de ejecución, lo que es imposible con la composición estática de
clases.

¿Cuáles veremos?

 Facade
 Adapter
 Composite

Facade:

Problema: El cliente hace muchos viajes al servidor. Separe por capas, pero tengo muchas clases
públicas en el servidor para que puedan ser creadas desde el cliente. Necesito estructurar las llamadas
desde el cliente.

Propósito: El patrón fachada se utiliza para proporcionar una interfaz unificada de alto nivel para un
conjunto de clases en un subsistema, haciéndolo más fácil de usar. Simplifica el acceso a dicho conjunto
de clases, ya que el cliente sólo se comunica con ellas a través de una única interfaz.

Motivación: El patrón fachada viene motivado por la necesidad de estructurar un entorno de

programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones
y dependencias entre éstos.

Consideraciones para su aplicación: Se aplicará el patrón fachada cuando se necesite proporcionar una
interfaz simple para un subsistema complejo, o cuando se quiera estructurar varios subsistemas en
capas, ya que las fachadas serían el punto de entrada a cada nivel. Otro escenario proclive para su
aplicación surge de la necesidad de desacoplar un sistema de sus clientes y de otros subsistemas,
haciéndolo más independiente, portable y reutilizable (esto es, reduciendo dependencias entre los
subsistemas y los clientes).

Adapter:

Problemas: Necesitamos llamar a un método a través de una interfaz para no tener dependencia en el
cliente. La librería a la que hay que llamar no es nuestra y no implementa esa interfaz. No contamos con
el código fuente de la librería.

Propósito: Convierte la interfaz de una clase en otra interfaz que el cliente espera. Adapter permite a las
clases trabajar juntas, lo que de otra manera no podría hacerlo debido a sus interfaces incompatibles.

También conocido como Wrapper (Envoltorio)

Aplicabilidad usar el patrón Adapter cuando: Se desea usar una clase existente, y su interfaz no se iguala
con la necesitada. Cuando se desea crear una clase reusable que coopera con clases no relacionadas, es
decir, las clases no tienen necesariamente interfaces compatibles.
Participantes: Target define la interfaz específica del dominio que Client usa. Client colabora con la
conformación de objetos para la interfaz Target. Adaptee define una interfaz existente que necesita
adaptarse. Adapter adapta la interfaz de Adaptee a la interfaz Target. Colaboraciones: Client llama a las
operaciones sobre una instancia Adapter. De hecho, el adaptador llama a las operaciones de Adaptee
que llevan a cabo el pedido.

Composite:

Problema: Estructuras de árbol o estructuras 1-N. Tiene un objeto complejo que hay que descomponer
en partes. Nodos especiales que pueden contener otros nodos.

Composite (patrón de diseño): El patrón Composite sirve para construir objetos complejos a partir de
otros más simples y similares entre sí, gracias a la composición recursiva y a una estructura en forma de
árbol. Esto simplifica el tratamiento de los objetos creados, ya que al poseer todos ellos una interfaz
común, se tratan todos de la misma manera.

Problema que soluciona: Imaginemos que necesitamos crear una serie de clases para guardar
información acerca de una serie de figuras que serán círculos, cuadrados y triángulos. Además
necesitamos poder tratar también grupos de imágenes porque nuestro programa permite seleccionar
varias de estas figuras a la vez para moverlas por la pantalla. En principio tenemos las clases Círculo,
Cuadrado y Triángulo, que heredarán de una clase padre que podríamos llamar Figura e implementarán
todas la operación pintar(). En cuanto a los grupos de Figuras podríamos caer en la tentación de crear
una clase particular separada de las anteriores llamada GrupoDeImágenes, también con un método
pintar().

Problema: Esta idea de separar en clases privadas componentes (figuras) y contenedores (grupos) tiene
el problema de que, para cada uno de los dos atributos, el método pintar() tendrá una implementación
diferente, aumentando la complejidad del sistema.

Patrones de comportamiento:

Propósito: Asignación de responsabilidad = Distribuir el comportamiento. Comunicación entre

instancias. Se usa mas la composición que la herencia.

¿Cuáles veremos?

 Command
 Strategy
 State

Command

Problema: Operaciones repetidas (por ejemplo, en el menú y en el toolbar). Necesita controlar la

secuencia de las operaciones. Necesito hacer un log de las operaciones que ejecuta el cliente.

Tambien puedo: Crear un método Deshacer en la Interfaz. Puedo crear una pila de los últimos comandos
que se ejecutaran. Puedo sacar de la pila de comandos ejecutados y llamar al método Deshacer.
Juntándolo con el patrón Composite puedo generar un comando Macro.
Propósito: Este Patrón permite solicitar una operación a un objeto sin conocer realmente el contenido
de esta operación, ni el receptor real de la misma. Para ello se encapsula la petición como un objeto, con
lo que además se facilita la parametrización de los métodos.

El Patrón permite: Encapsular un mensaje como un objeto, con lo que podemos gestionar colas o
registros de mensajes y deshacer operaciones. Soportar restaurar el estado a partir de un momento
dado. Ofrecer una interfaz común que permita invocar las acciones de forma uniforme y extender el
sistema con nuevas acciones de forma más sencilla.

State:

Problema: Mantener el estado de un objeto. La organización de la lógica que maneja el estado (maquina
de estado) se torna incontrolable. Acoplamiento entre la funcionalidad propia de la clase y la
funcionalidad para manejar el estado de un objeto. El patrón de diseño State se utiliza cuando el
comportamiento de un objeto cambia dependiendo del estado del mismo. Por ejemplo: una alarma
puede tener diferentes estados, como desactivada, activada, en configuración. Definimos una interfaz
Estado_Alarma, y luego definimos los diferentes estados.

Observer:

Problema: Mantener distintos objetos relacionados, generalmente son relaciones 1 – N. Mantener las
dependencias entre objetos, sin necesidad de conocer al otro objeto.

Tipos de objetos:

 Publicador: Aquel que tiene que notificar de un cambio.

 Suscriptores: Aquellos interesados en recibir la notificación.

El patrón Observador (en inglés: Observer) también conocido como "spider" define una dependencia del
tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, el
observador se encarga de notificar este cambio a todos los otros dependientes. El objetivo de este
patrón es desacoplar la clase de los objetos clientes del objeto, aumentando la modularidad del
lenguaje, así como evitar bucles de actualización (espera activa o polling). Este patrón también se
conoce como el patrón de publicación-inscripción o modelo-patrón. Estos nombres sugieren las ideas
básicas del patrón, que son bien sencillas: el objeto de datos, llamémoslo "Sujeto" a partir de ahora,
contiene atributos mediante los cuales cualquier objeto observador o vista se puede suscribir a él
pasándole una referencia a sí mismo. El Sujeto mantiene así una lista de las referencias a sus
observadores. Los observadores a su vez están obligados a implementar unos métodos determinados
mediante los cuales el Sujeto es capaz de notificar a sus observadores "suscritos" los cambios que sufre
para que todos ellos tengan la oportunidad de refrescar el contenido representado. De manera que
cuando se produce un cambio en el Sujeto, ejecutado, por ejemplo, por alguno de los observadores, el
objeto de datos puede recorrer la lista de observadores avisando a cada uno.

Otras consideraciones:

Puedo enviar la información necesaria a los suscriptores al notificar o que pida lo que necesita
(dependencia hacia el publicador) Ante casos de muchos publicadores, puedo hacer un Gestor de
Cambios que haga la función de mediador. Al notificar se puede usar delegados y pasar clases que
hereden de EventArgs al Suscriptor.