Patrones GoF: Composite y Observador

[[Delphius]]

Hola a todos.
No se de que manera expresarme sobre este tema...

Vengo leyendo y re-leyendo una y otra vez algunos patrones GoF para ver si logro comprender su uso y analizar los modelos con que estoy trabajando.
Entiendo la mayoría de los patrones, pero por más esfuerzo y concentración que le dedico al tema no termino de asimilar lo que propone Composite y Observador.

De lo que he podido asimilar (les pido que me corrijan si me equivoco por favor), Composite define a una clase que forma una lista de otra clase que la define a la primera.

¿Es así? La verdad es que no logro entender la solución y el contexto del problema. No logro imaginarme un problema en donde Composite sea aplicable.
Por el momento, no veo en mis modelos algo así como un grupo de elementos que se "guarde" a si mismo.
No me es urgente comprender este concepto... pero quisiera poder llegar a dominarlo para un futuro.

Leí no se cuantas veces UML y Patrones, busqué en internet y quedé más confundido...

Por otro lado, también tengo problemas para entender el patrón Observador. De lo que creo entender... Observador define y propone una interfaz que escucha algún evento que es disparado por alguna clase que implementa dicho evento.
El ejemplo que expone Craig Larman en su libro se suena a chino, y lo único que logro interpretar es que mágicamente una clase envia algún mensaje a una interface que envia la orden de actualizar un valor en pantalla.

Se que mi falta de comprensión se debe al hecho de que no manejo el concepto de interface, sobre todo lo que en Delphi significa.

A lo fines y objetivo de mi trabajo no he considerado estar analizando y comprender lo que permite y para que se emplea interface (mucho de lo que lei de La Cara Oculta en este asunto... no le di demasiada importancia) ya que me resulta demasiado complejo y elaborado, y escapa a los límites a lo que estoy dispuesto a aceptar en mi trabajo.

Lograr comprender Observador muy seguramente me ayude a comprender de que manera enganchar la capa de interfaz y la de dominio. Al menos eso me da a entender este patrón.

Se que no soy un experto en patrones, he comprendido y puesto en práctica los más habituales. Y con el tiempo he logrado aplicarlos en forma intuitiva... pero a estos dos no termino de asimilar.

Como dije, he leído varios links y me han dejado mucho más confuso. Al tema de los patrones no los he visto en la universidad, nunca los hemos puesto en práctica. Y la referencia bibliográfica de la biblioteca es escasa: solo disponen de UML y Patrones. Por mi cuenta, he seguido y estudié el tema.

Para finalizar mi exposición, quiero comentar que mi idea no es aprenderme todos los patrones, solo más habituales, importantes y conocidos. Si alguien conoce UML y Patrones, tal vez entienda de lo que hablo. Yo vengo siguiendo sus conceptos. Y a los fines de mi proyecto, considero útil lo expuesto hasta el capítulo 29. Hasta el momento me han servido.

Para mayor info: uso UML y Patrones. Una introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado. Segunda Edición.

Me gustaría saber si alguien conoce del tema y darme alguna refencia sobre el tema. Si es posible, con algún ejemplo... admito que esta vez, estoy en un punto en el que no se como seguirlo.

Muchas gracias por su ayuda, comprensión y tiempo dedicado.
Los saluda un estudiante un poco desesperado

[[Al González]]

¡Hola a todos!

¿Qué puedo decirte Marcelo? En los últimos años no he leído ningún libro de informática, pero trataré de ayudarte con algo que se parece a esto que mencionas:

Empezado por Delphius

...Composite define a una clase que forma una lista de otra clase que la define a la primera...

Es curioso, pero precisamente en este momento tengo mi Delphi 7 abierto porque estoy trabajando en una serie de clases que se asemejan a ese concepto que jamás había escuchado. Tal vez no se trate de lo mismo, pero te expongo de manera muy simplificada mi caso:

Tengo dos clases, TSavePoints y TSavePoint, las cuales me sirven para implementar puntos de restauración (save points). Una instancia de la primera contiene una lista de instancias de la segunda clase. Es decir, TSavePoints es una lista de objetos TSavePoint. Los mecanismos esenciales del punto de restauración (una serie de métodos virtuales llamados InternalConfirm, InternalDestroy, InternalRestore e InternalSave) se definen en la clase TSavePoint, mientras que la clase TSavePoints sólo es quien crea, agrupa y coordina los puntos.

La clase TSavePoints carecería de sentido sin la clase TSavePoint, de alguna manera podría decirse que la segunda "define" a la primera. La clase TSavePoints existe porque los puntos de restauración no pueden ser autónomos, dependen unos de otros, por lo tanto algo debe agruparlos y coordinarlos. Si creo (salvo) sucesivamente los puntos sp1, sp2 y sp3 y posteriormente restauro el punto sp2, sp3 debe desaparecer. Un ejemplo clásico de esto son los puntos de restauración que algunas bases de datos permiten dentro de transacciones, o los puntos de restauración que tiene Windows XP para cuando algo que instalaste quedó mal y quieres revertirlo.

Un ejemplo típico de Delphi podrían ser las clases TMenu y TMenuItem. Pero insisto en que tal vez esto no tiene nada que ver con lo que tú estás estudiando porque desconozco por completo el tema de los patrones.

Empezado por Delphius

...Se que mi falta de comprensión se debe al hecho de que no manejo el concepto de interface, sobre todo lo que en Delphi significa...

En cuanto a las interfaces, es uno de esos temas que empiezan con cara de "a ver si puedes conmigo" y terminan siendo una simplonada más de programación.

Una interfaz es una especie de definición de clase, en la cual pueden aparecer declaraciones de métodos y propiedades (como en una declaración de clase normal). La diferencia es que no le pones código a esos métodos y no puedes crear un objeto (instancia) de dicha clase. "¿Entonces pa' qué sirve? ¿dónde va el código de los métodos?", preguntarás. Simple: el código (implementación) lo pones como parte de una clase normal.

¡Ahchis! ¿Y esa clase normal también debe declarar los métodos?

Sí.

¿Entonces pa' qué declaro la interfaz?

Para darle un nombre o "identificador" a ese grupo de métodos y propiedades y poder trabajar con dicho grupo como si fuese un objeto aparte.

Pero has dicho que no pueden crearse instancias de una interfaz.

Así es, por eso es que una clase debe implementar sus métodos.

¿Pero entonces por qué no declaro e implemento esos métodos y propiedades nada más en la clase normal y me olvido de usar una interfaz?

Si haces eso, ese grupo de elementos perderán su esencia de "tipo de objeto" y terminarán siendo métodos y propiedades comunes y corrientes de la clase. En cambio, una interfaz sirve para "etiquetar" a diversas clases de objetos no derivadas entre sí, dándole un comportamiento común a todas ellas, como si tuvieran un nuevo ancestro común paralelo, adicional a los ancestros que ya poseen. Un objeto de clase T1 que implemente la interfaz I1, podrá ser tratado como un objeto de tipo I1. Un objeto de clase T2 que implemente la misma interfaz, también podrá ser manejado como objeto de tipo I1. Entonces ya tienes dos objetos de clases diferentes (T1 y T2), pero que para ciertos propósitos pueden ser tratados como si fueran de la misma clase; y ya sabes que cuando puedes tratar a dos o más objetos de la misma manera, tu código se simplifica. Esto es una especie de polimorfismo forzado

¡Ah!, se parece mucho a la herencia múltiple de C++.

De hecho es la forma de emplear herencia múltiple en Delphi, pero de una manera más controlada.

¿Y sólo para eso sirven las interfaces?

No, también son muy importantes para permitir que los objetos de diferentes aplicaciones en ejecución se comuniquen entre sí, incluso si dichas aplicaciones corren en diferentes máquinas y fueron escritas en otros lenguajes. Las interfaces son una manera estandarizada de conectarse a los objetos de otro programa, sin importar cómo están implementados dichos objetos. Por eso se llaman interfaces (en singular interfaz), porque son como una ventana o conexión hacia lo que está del otro lado, pero bajo una forma que es comprensible para quien, desde este lado, lo utiliza.

Gracias Al. ¿Estarás por aquí mañana?

¡Hasta crees! Mañana es quincena.

Un IAbrazo.

Al González.

P.D. Perdón si dije alguna tarugada, no domino el tema de las interfaces.

[[Delphius]]

Empezado por Al González

P.D. Perdón si dije alguna tarugada, no domino el tema de las interfaces.

Para mi no fue una taradez. Me ha gustado tu explicación de las interfaces, creo poder entenderlas ahora... aunque le veo todavía un poco demasiado para lo que yo ando haciendo. Por el momento con mis objetos me valido.

Lo que dices sobre tu caso de los SavePoint, me suena al Composite, aunque le veo también un aire o mezcla con el patrón Creador. De hecho, los problemas de los patrones es saber cual de patrones es el más adecuado a seguir.

No se que tan difundido sea el uso de patrones... al menos yo le veo utilidad. Aunque esta es la primera vez que los vengo poniendo en práctica para algo "serio".

Me voy a tener que sentar a estudiar mejor esto...
Muchas gracias por ayudarme Al. Que tengas éxito con los SavePoints.

Saludos,

[[maeyanes]]

Estuve buscando sobre el patrón Composite y esto fue lo que encontré:

http://www.delphi3000.com/articles/article_3595.asp

En ese artículo tienes un buen ejemplo en Delphi sobre este patrón.

En si, este patrón dice que permite a cierto objeto tratar objetos individuales y composiciones de objetos de manera uniforme.

Un pequeño ejemplo:

Código Delphi [-]
TComponentClass = class
protected
  procedure DoSomething: virtual;
end;

TCompositeClass = class(TComponentClass)
private
  ComponentList: TList;
protected
  procedure DoSomething; override;
public
  constructor Create;
  destructor Destroy; override;
end;

implementation

procedure TComponentClass.DoSomething;
begin
  ShowMessage('Componente individual');
end;

constructor TCompositeClass.Create;
begin
  ComponentList := TList.Create;
end;

destructor TCompositeClass.Destroy;
begin
  ComponentList.Free
end;

procedure TCompositeClass.DoSomething;
var
  I: Integer;

begin
  for I := 0 to Pred(ComponentList.Count) do
    TComponentClass(ComponentList[i]).DoSomething
end;

Espero que con este ejemplo y el artículo que enlacé te quede más claro el patrón Composite.


Saludos...

[[Delphius]]

Empezado por maeyanes

Estuve buscando sobre el patrón Composite y esto fue lo que encontré:

http://www.delphi3000.com/articles/article_3595.asp

En ese artículo tienes un buen ejemplo en Delphi sobre este patrón.

En si, este patrón dice que permite a cierto objeto tratar objetos individuales y composiciones de objetos de manera uniforme.


Espero que con este ejemplo y el artículo que enlacé te quede más claro el patrón Composite.
Saludos...

Muchas gracias por tomarte la molestia maeyanes. Con el ejemplo en delphi se lo entiende mejor. Al menos ya le perdí el miedo.
El artículo es sencillo, breve y fácil de entender. ¿Porqué otros se esfuerzan demasiado en explicar algo que resulta ser un poco más simple? Ya ni recuerdo de donde había leído... no había buscado en dicho sitio. ¡Muchísimas gracias!

Probé buscar en delphi3000 sobre Observer... el ejemplo está un poquito más lioso, pero creo que si leo bien el artículo voy a comprender mejor el asunto.

Gracias a ambos por tomarse su tiempo.

Saludos