Patrones GoF: Composite y Observador

[[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