Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > OOP
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Coloboración Paypal con ClubDelphi

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 31-08-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Patrones GoF: Composite y Observador

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
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #2  
Antiguo 31-08-2007
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: may 2003
Posts: 5.609
Poder: 30
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Smile

¡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:
Cita:
Empezado por Delphius Ver Mensaje
...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.

Cita:
Empezado por Delphius Ver Mensaje
...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.

Última edición por Al González fecha: 31-08-2007 a las 10:30:09.
Responder Con Cita
  #3  
Antiguo 31-08-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Cita:
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,
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
  #4  
Antiguo 31-08-2007
[maeyanes] maeyanes is offline
Capo de los Capos
 
Registrado: may 2003
Ubicación: Campeche, México
Posts: 2.732
Poder: 24
maeyanes Va por buen camino
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...
Responder Con Cita
  #5  
Antiguo 31-08-2007
Avatar de Delphius
[Delphius] Delphius is offline
Miembro Premium
 
Registrado: jul 2004
Ubicación: Salta, Argentina
Posts: 5.582
Poder: 26
Delphius Va camino a la fama
Cita:
Empezado por maeyanes Ver Mensaje
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
__________________
Delphius
[Guia de estilo][Buscar]
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Auto Cad 2002/2006 pagado de patrones de sombra arquifer Windows 0 10-07-2007 23:15:36
Más problema padrón observador adpa OOP 5 07-02-2007 21:19:15
Patrón observador, attach, notify,update ... adpa OOP 5 22-01-2006 02:07:40
diseño de patrones pablo Gráficos 0 13-04-2005 21:26:25
De Patrones y Empleadas. marcoszorrilla Humor 1 17-04-2004 02:05:05


La franja horaria es GMT +2. Ahora son las 01:55:06.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi