19 respuestas en este tema

[Rolphy Reyes]

Saludos.
En estos últimos tiempos he estado digiriendo patrones de diseño, los clásicos (Observador,  Adaptador, Fachada, Singleton y así por el estilo).  Y he dado el "salto" para MVC, MVP y algunos derivados (estudio a fondo, ya estaba familiarizado con los términos).
Todas las implementaciones de dichos patrones, sin importar el lenguaje, pero concretamente en Delphi  prácticamente renuncian al uso de los componentes DB Aware (de plano en la Web no existen) así como del TDataSet; se trata de imitar la manera del Data Binding de .NET o por lo menos es mi apreciación.Entonces yo me pregunto, ¿Debo de renunciar al RAD de Delphi?, teniendo en cuenta que es lo más poderoso que posee nuestra herramienta.  También ¿Debo de renunciar al poder que me dan los TDataSet? el cual me evita un monto de código.
Alejándome un poco de esas interrogantes, me surge una duda conceptual, para tratar de llegar a construir algo parecido al MVP (o por lo menos se parezca al Passive View aunque sea de manera remota) tengo el siguiente escenario y claro es mi apreciación:

• M = Base de Datos
• V = Formularios (TForm)
• P = Data Modulo (TDataModule)

Cada tabla tiene su TDataModule en la aplicación, cabe aclarar que dentro de esa clase se tiene un TDataSet que representa dicha tabla para realizar todas las operaciones de lugar, ganando con esto que toda la lógica de manejo para esa entidad esta en un solo sitio.
Ahora bien, los Formularios tienen una propiedad tipo TDataModule para poder invocar los métodos necesarios (Insertar, Editar, Borrar...).  Con esta modalidad ¿Estaría rompiendo el modelo MVP? ¿Estaría violando las leyes de Demeter?
Analizando dichas interrogantes y siendo afirmativas las respuestas, me dije, lo ideal seria implementar el patrón Fachada y así podre solventar dichas situaciones. Con esto ya el Formulario no conocería al TDataModule sino a la clase TFachadataModule, por ende, la propiedad (del formulario) pasaría de TDataModule a TFachadaModule.
Pero me surge (siempre un pero) otra interrogante, cuando tenga la necesidad de crearme un método especifico para un DataModule por ejemplo, para el DataModule de Empleados para manejar su salario; ¿Tendría que implementar dicho método en el DataModule y luego hacer una herencia de TFachadaModule a su vez hacer un wrapper de ese método y poner en uso esa nueva unidad en el formulario del empleado?En verdad ando algo en liado con estos conceptos    y ni hablar de Dependency Injection y sus variantes.
En realidad ando buscando acercarme lo más posible a MVP, pero sin renunciar al RAD de Delphi.
Espero que se pueda entender algo...
P.D. No se que le pasa a mi Chrome que hace que se vea así 

[Marc]

¿ Has evaluado InstantObjects ?.

http://www.instantob....org/index.html

Y es que para modelizar la base de datos, este es el único ORM que conozco para Delphi que está diseñado para su uso con componentes data-aware.

Como bien dices, para mi el RAD también es irrenunciable. Creo que este framework (muy promocionado por Marco Cantú) es de el más indicado para trabajar de esta forma. Lamentablemente nunca he tenido tiempo para probarlo como se merece.

NOTA: Aunque la última versión ya tenga unos cuantos años, la van actualizando para incluir mejoras y soportar las nuevas versiones de Delphi (lo que no sé es para cuando tienen prevista la salida de InstantObjects 3).

[Rolphy Reyes]

¿ Has evaluado InstantObjects ?.

http://www.instantob....org/index.html

Y es que para modelizar la base de datos, este es el único ORM que conozco para Delphi que está diseñado para su uso con componentes data-aware.

Como bien dices, para mi el RAD también es irrenunciable. Creo que este framework (muy promocionado por Marco Cantú) es de el más indicado para trabajar de esta forma. Lamentablemente nunca he tenido tiempo para probarlo como se merece.

NOTA: Aunque la última versión ya tenga unos cuantos años, la van actualizando para incluir mejoras y soportar las nuevas versiones de Delphi (lo que no sé es para cuando tienen prevista la salida de InstantObjects 3).

Saludos.

Gracias Marc, lo había escuchado solo que desconocía la característica del soporte a Data Aware.

En la medida de lo posible le echare un ojo, y como ambos coincidimos es difícil ya a este punto renunciar al RAD.  Sería como renunciar al mismo Delphi, considero.

[andres1569]

¿Alguien me puede explicar cuáles son las ventajas del DataBinding al estilo de .NET? Desconozco en gran parte su funcionamiento, lo único que he leído es que se ligan los controles por código con los contenedores de datos. Esto puede dar mayor flexibilidad al habilitar a más tipos de controles el acceso a datos tomados de una BBDD, pero por contra supone inyectar más código a la aplicación, y no es por el trabajo "extra" para el programador de teclear más o menos, sino qué ventajas aporta esa forma de hacer las cosas frente al modelo DBAware, tipo RAD y quizás más estricto, que conocemos en Delphi.

Mi idea preconcebida de todo esto es que son ganas de hacer experimentos, aunque ya digo que no lo conozco demasiado, pero sí he leído opiniones de gente que sí lo usa en .NET quejándose de esa forma de operar.



Gracias.

[Rolphy Reyes]

Saludos.

Hola Andres, al igual que tú desconozco también el funcionamiento per se del DataBinding; la única ventaja que le encuentro de momento es que cualquier control estándar pasa como DBAware.

Claro esta que debes realizar tú mismo la función del TDataSource, me refiero a las notificaciones que dicho componente realiza.

[Delphius]

Hola Rolphy Reyes,
Me encantaría poder tener una respuesta bien precisa a tu pregunta pero por el momento no la tengo. En primer lugar si bien entiendo superficialmente al concepto de Modelo-Vista-Controlador, no lo he estudiado. En buena parte como te comenté en otras ocasiones porque había dejado en stand-by el estudio sobre los patrones.

Por lo que veo te has dedicado muy fuerte a estudiar el tema, te envidio. Creo en mi más humilde opinión que mucho no puedo decir... Veo que mis opiniones y consejos han sido bien recibidos y le sacaste mucho provecho.

Llegaste a casi las mismas conclusiones que yo: los componentes Data-ware escapan al concepto de MVC. En parte porque la arquitectura:

data-ware -> DataSource -> DataSet

Implica una vinculación desde lo visual hacia la capa de datos.

Yo desde que empecé a estudiar Delphi con bases de datos, junto con la teoria OO y a interiorizarme sobre los patrones no me sentí muy allegado a los componentes Data-ware.

Reconozco que estos son una gran ventaja y nos ayudan y facilitan mucho el diseño de sistemas. Sin embargo, considero que en cuanto la mayor parte de la complejidad del sistema está envuelta en la capa lógica es necesario ampliar esa visión y optar por diseño apoyado en el patrón Layers y seguir el esquema multi-capa. Es así que puede esperarse de las capas Aplicación, Dominio e Infraestructura de Negocio.

Ante un escenario como éste, seguir con el diseño Data-ware es más una desventaja porque dificulta llevar un adecuado control de la lógica del negocio.

Esto no quiere decir que debamos abandonar la potencia de Delphi. Considero que la potencia de Delphi no debe ser vista únicamente por el lado RAD y el uso de Data-ware sino de su rica y bien pensada VCL y su fácil manejo para utilizar el paradigma OO.

Déjame decirte, que parcialmente, el uso de esta arquitectura data-ware aplica los mismos conceptos esenciales y bases en que se apoya MVC: el patrón Observador o Observer.

El DataSource hace de puente entre los componentes Data-ware y el DataSet. Escucha las peticiones desde el lado data-ware, luego las redirige al DataSet y ante una respuesta la propaga al componente data-ware apropiado. Esta arquitectura se apoya en una clase auxiliar, DataLink que vendría a ser una especie de indirección entre el DataSource.

No es del todo errado el concepto que han seguido. Es una solución elegante, y estable y que evita complicar más el diseño del framework dedicado a base de datos que tiene la VCL.
Ten presente que uno cuando diseña pensando en OO, y sobre todo siguiendo los conceptos que proponen los patrones, debe poner en la balanza muchos factores y cada uno tiene pros y contras.

Seguramente tienes bien presente que a veces seguir un patrón no conduce a una mejora, sino que entorpece o nubla el diseño original. Algunos patrones implican un cambio radical en la arquitecura porque o bien añade más clases de las que estábamos contemplando o bien porque sugieren otra forma de vincular y relacionarlas.

En su momento pensé que la solución más salomónica y equilibrada era seguir por la aplicación del Observador y emplear Fachadas/Controlador (y muy posiblemente apoyado en otros patrones vinculados para sus clases auxiliares) para vincular las capas Dominio y Aplicación junto con la de Presentación (que vendría a ser la dedicada al soporte exclusivamente a la Interfaz) y la capa Base (que entre otras aplicaciones y rutinas básicas de muy bajo nivel se incluye el acceso a Base de Datos).

Algo de eso veo en tus explicaciones y creo que tu mismo encontrarás la respuesta que buscas.
Mi consejo es que te no presiones demasiado, no es nada sencillo y ya lo comprobaste, absorber los conceptos de los patrones... Son tantos (cientos) y están tan relacionados (e incluso algunos similares o con algunas pocas variaciones). No quiero que te pase lo que me pasó a mi: mi cabeza hizo pum.
Esto es lo que lleva a algunos detractores que el tema de los patrones ha sido sobredimensionado... y argumentan que muchos de los patrones podrían obviarse o podrían encararse con los elementales.

No te dejes abrumar demasiado por los patrones. Como dice Larman, hay que tener cuidado de no agarrar la enfermedad patronitis.
A veces nos complicamos demasiados pensando en aplicar patrones a rajatablas y si hubiéramos optado por otras alternativas quizá pudiéramos haber avanzado más rápido y de una forma más simple.

Lo que se busca con los frameworks ORM o Mapping O-R es llevar el diseño de la base de datos hacia el plano de los objetos. Esto no es tan sencillo de encarar puesto que no existe una correspondencia directa entre uno y otro. La idea es supuestamente facilitar el diseño de la capa de Dominio generando clases conceptuales que representen las entidades (las tablas) y conseguir una mejor separación contextual entre lo que hace a funciones orientadas a las bases de datos (en la jerga ORM: persistencia) [Esto está repartido en la VCL entre los DataSet, los Fields, los parámetros TParams y Parameters] de las funciones orientadas al contexto o conceptualización.

Estas bibliotecas o framerworks de persistencia no están en contra del concepto DataSet, es que lo ven de una forma un tanto diferente: hablan de objetos persistentes que representen a las tablas. ¿No es acaso un DataSet cualquiera una abstracción de una tabla o un conjunto de datos? El punto es que estos frameworks añaden a estos objetos persistentes los métodos orientados al contexto. Por ejemplo, Si tenemos la clase FacturaPersistente, es posible que entre sus métodos esté GuardarFactura. En el esquema DataSet el concepto es un método Post.
No es más que elevar la abstracción.

La forma en como está diseñado el DataSet, su colección de Fields y Parámetros es un framework de persistencia; genérico pero en fin es uno más. No por ello deberíamos descartarlo.

Respecto a la violación de la Ley de Demeter (que dicho sea de paso, forma parte del "patrón" Variaciones Protegidas) Lo único a lo que hace referencia es el anidamiento o el alcance del conocimiento de una clase sobre otra. Básicamente la ley ofrece una guía o consejo práctico que siguiere que una clase no debe hablar con ninguna otra que no le sea de interés... Es más fácil entenderlo si mencionamos el nombre alternativa a la ley: No hables con extraños.

Esta ley dice que deberíamos tener cuidado a quien enviamos mensajes. Dice que un método sólo debería enviar mensajes a:
1. La clase misma o mejor conocida como this o self.
2. Un parámetro del método
3. Un atributo de la clase
4. Un elemento de la colección que sea atributo de this
5. Un objeto creado en el método

Siguiendo estas práctica, se consigue reducir el acoplamiento con otras clases.
Una buena regla es no enviar mensajes más hallá de dos clases, por ejemplo:

Objeto1.Ob1EnviaMensajeObj2().Obj2EnviaMensajeObj3().

De este modo el objeto1 estará enviando un mensaje al Objeto 3, en forma indirecta. Esto viola parcialmente la regla... ¡no es un gran pecado! Aunque lo adecuado sería que Obj 1 sólo llevara hacia Obj 2 y no tener que conocer al Obj 3.

Más hallá de este nivel no es aconsejable. Más que ley debería llamarse Principio, suena más permisivo y uno no siente que va en contra. NO deberías tomártelo tan a pecho.

A mi entender, que un Formulario hable con un DataModule no es una violación; sobre todo si es que ese formulario tiene una propiedad directa. Es un caso práctico, y totalmente legal y esperado (*), del punto 2 y 3.

(*) ¿De que otro modo comunicamos ambas capas?... Si es que el sistema no amerita tener que llevar a un diseño Multicapa como la de Aplicación y Dominio. Además, Delphi de forma automatica nos permita llevar este sistema.

Ahora bien, si se sigue el diseño basado en Fachada/Controlador, esta fachada debería centrarse en la capa de dominio y desde ésta tener vínculos con una Fachada localizada en la Capa de Datos. Es decir la capa interfaz (compuesta por los forms) se comunica con una Fachada/Controlador que asume y controla la capa de Dominio. Luego, viene la Fachada que está localizada en la capa de Datos (o Base).

Ten en cuenta que lo ideal es que la Capa Dominio (o la Capa Lógica, si nos apegamos al diseño en 3 capas) haga de INTERMEDIARIO entre Interfaz y Datos.

Sobre Pasive View no sabría decir... no conozco ese término.

Se que quizá no he sido de mucha ayuda y que traigo más dudas que respuestas... Yo también me siento así. Yo me convencí hace tiempo que estudiar los patrones, MVC y Mapping O-R, es leeeennnnnto... un trabajo de meses (hasta años) para que la cabeza se vaya adaptando a absorber las cosas.

Saludos,

[Alfredo]

Hola que tal!, mira te cuento como trabajo, ojala te pueda dar una idea.

En los códigos que he visto que usan un form y un datamodulo para separar las capas de la aplicación generalmente me doy cuenta que sigue existiendo el acoplamiento entre las formas y los datamodulos
Es usual ver codigo parecido a esto:

delphi

procedure TfrmDatosGenerales.btnAsignarClick(Sender: TObject);
begin
dmDatosGenerales.tblDatGral.Insert;
//algun proceso
dmDatosGenerales.tblDatGral.Post;
end;

Esta aproximación le da el control a la visualización, cuando deberia ser que el control lo tenga el datamodulo por que ahi estan los procesos de negocios; la forma es solamente la representacion de los datos que se manejen en el datamodulo.
Por tanto podemos hacer lo siguiente.

delphi

  TdmDatGrales = class(TDataModule)
...
    tblDatGrales : TTable;
    ActnList: TActionList;
    actAsignar: TAction;
...    
  private
     PropForm : TfrmDatGrales;
    { Private declarations }
  public
    { Public declarations }
    constructor Create (aOwner : TComponent);override;
    destructor Destroy;override;
    procedure ShowModal;
  end;
implementacion
 
constructor TDmDatGrales.Create(AOwner : TComponent);override;
begin
inherited;
PropForm := TfrmDatGrales.Create(Self);
PropForm.DataSet := tblDatGrales;
PropForm.Asignar := actAsignar;
end;
 
destructor TdmDatGrales.Destroy;override;
begin
PropForm.Free;
inherited;
end;
 
procedure TdmDatGrales.actAsignarExecute(Sender: TObject);
begin
tblDatGral.Insert;
//algun proceso
tblDatGral.Post;
end;
 
procedure TdmDatGrales.SHowModal;
begin
PropForm.ShowModal;
end;

delphi

  TfrmDatosGrales = class(TForm)
...
  private
...
  public
    { Public declarations }
    property Asignar : TAction read FAsignar write SetAsignar;
    property DataSet : TDataSet read FDataSet write SetDataSet;
  end;
implementacion
 
procedure TfrmDatosGrales.SetDataSet(Value : TDataSet);
begin
dataSource.DataSet :=Value;
end;
 
procedure TfrmDatosGrales.SetAsignar(Value : TAction);
begin
 btnAsignar.Action := Value;
end;

De esta manera en la forma no hay referencias explicitas a objetos que se encuentren en el datamodulo.
Espero no haber dicho cantinfleadas.. jejejeje

[Rolphy Reyes]

Saludos.

@Delphius necesito tiempo para asimilar por completo tu idea.  Ahora bien, coincido en que al parecer hemos llegado a un "callejón sin salida" y también de que MVC/MVP se escapa de los Data Aware.

De todos modos, tratare de construir algo que contenga principios de MVP. Gracias por darme animo a continuar...

@Alfredo Desde un punto de vista tu planteamiento no esta mal; pero a mi entender haces el acoplamiento al revés lo cual no es bueno (a mi entender) si decidieras en un futuro cambiar tu View te puede traer sendos problemas.

No soy un experto en el tema, lo ando estudiando, veré como mejoro los conceptos y espero poder compartirlo con ustedes.

[Rolphy Reyes]

Chic@s

Enlace sobre Passive y DataBinding para Delphi.  La pega es que el DataBinding esta hecho para D2009+.

[Delphius]

Saludos.

@Delphius necesito tiempo para asimilar por completo tu idea.  Ahora bien, coincido en que al parecer hemos llegado a un "callejón sin salida" y también de que MVC/MVP se escapa de los Data Aware.

De todos modos, tratare de construir algo que contenga principios de MVP. Gracias por darme animo a continuar...

Y yo también necesito tiempo para entender mis guisados mentales 
Yo en vez de verlo como el callejón sin salida, prefiero verlo como esos juegos de aventuras en el que debes ir recolectando objetos y resolviendo rompecabezas en base a pistas. Ahora me encuentro en la segunda mitad del juego pero me faltan unos objetos, pistas y rompecabezas para seguir. 

@Alfredo Desde un punto de vista tu planteamiento no esta mal; pero a mi entender haces el acoplamiento al revés lo cual no es bueno (a mi entender) si decidieras en un futuro cambiar tu View te puede traer sendos problemas.

Efectivamente, el acoplamiento está invertido, y no es deseable eso... al menos no con esa técnica.

Ya sea que se haga desde A hacia B o desde B hacia A, el acoplamiento está (y estará). ¡No se puede eliminar el acoplamiento! Si esa es la intención que buscan.
Una clase que no se pueda acoplar, es una clase sin sentido práctico. ¿De que sirve una clase que no se puede vincular, asociar, ni delegar? Es una todologa-nada. No tiene sentido de existencia.

De algún modo debe de existir acoplamiento, y el que se haya hecho a la inversa no lo reduce, de hecho es el mismo.

Lo más adecuado si es que se quiere seguir el diseño apoyado en patrones es emplear Observer. La idea básica es que el form se "registra" en la lista de un Controlador/Fachada que hace de Publicador y se queda esperando a la escucha de los mensajes que se le envíe.

Es decir, el Form actuará de Observador/Oyente, y una Fachada que controla y dirige toda la capa Dominio es la irá enviando los mensajes a sus Oyentes.
Esta Fachada en realidad no reconoce a ningun Form, sino a una interfaz de común acuerdo que entienden tanto el Publicador como los Observadores. La idea es que el Publicador, Emisor o Sujeto tenga una lista de oyentes (ya sea que en realidad sea uno).
Del mismo modo, los Forms no están vinculados a un DataModule sino a una interfaz... un tipo al que conocen unicamente como el "loco ese que me dice las noticias".

Hemos creado cierta indirección, el acoplamiento entre el Form y los DataModule pasa a través de una Fachada, no hay conocimiento total de uno y otro lado.

El Sujeto no conoce realmente quienes son los oyentes (el simplemente saben que hay, o cuanto mucho interpreta a sus oyentes como un objeto abstracto, para el caso de Delphi decimos que entiende a todo como TObject). Los oyentes por su parte desconocen lo que sucede adentro del sujeto... simplemente conocen a ese sujeto como una clase TSujeto; si éste, internamente, está vinculado a un TDataModule o lo que fuese... ni se enteran.

La "interfaz" común y lo que permite enviar las noticias a los oyentes no es más que un evento. Los oyentes deben implementarlo y el sujeto sólo se encarga de decirles "Dispara el evento tal". Entonces, ya es sólo responsabilidad de cada oyente el implementar adecuadamente la respuesta a dicho evento según como le guste o necesite.

¿Se entiende? El acoplamiento es desde el Oyente al Sujeto; Para el caso discutido, desde el Form al Sujeto.

Más info sobre el patrón Observer, aquí. Yo sugeriría que leyeran el libro UML y Patrones, de Craig Larman. Ofrece una explicación y ejemplo bastante claro del patrón.

La ventaja de este acomplamiento es que es débil. Puede "romperse" cuando sea necesario, si un oyente ya no desea seguir recibiendo las noticias debe cancelar su suscripción.

Saludos,

[Rolphy Reyes]

Saludos.

¿@Delphius sabes que existen dos tipos de patrón Observador?

• Pull
• Push

O por lo menos así lo clasifica el autor de los enlaces anteriores.

[Rolphy Reyes]

Saludos.

Algo que si note, es que los Frameworks:

• Passive View
• MVP (Jazz)
• MVP (Joanna Carter)

Utilizan interfaces al máximo, lo que me recuerda este hilo. 

[Delphius]

Saludos.

¿@Delphius sabes que existen dos tipos de patrón Observador?

• Pull
• Push

O por lo menos así lo clasifica el autor de los enlaces anteriores.

Pues, en realidad no.
En mi libros y en lo que leí sobre el Patrón nunca he visto algo sobre Observer Pull u Observer Push.

Recuerdo vagamente, algo de Pull y Push, aunque no específicamente ligado al patrón Observador o que fueran tipos del Observador, sino como técnicas que se han sugerido de como implementar el envío y recepción de mensajes.

Pull, a como lo tengo entendido, es la técnica en la que un grupo de objeto "tira" de un objeto para sacarle la información. Es decir el Oyente es quien envía la orden y el Sujeto respondía. Es decir realmente el oyente no "escucha" sino que le ordena al sujeto que le enviase el dato.

Por el otro lado, la técnica Push es la que describí. El Sujeto es quien envía la orden a sus oyentes. Yo tengo entendido que el patrón Observador, puro y por definición, es Push.

La técnica Pull es el estilo típico de un diseño basado en mandos, Un objeto A manda a B y luego B le responde. La típica órden o envío de mensajes. Push, por el contrario, la forma en como uno envía mensajes a un grupo.

El problema que propone responder el Patrón es el sentido inverso... es decir evitar que las clases interesadas "maltraten" o tiren del sujeto (que es la clase que tiene la información a la que otras quieren acceder). En el patrón Observador se le da responsabilidad al Sujeto de avisar a sus oyentes o interesados de algo y evitar que tironeen de él.

En parte este patrón está motivado e influenciado por el patrón Experto en Información. Si el Sujeto tiene la información, y son varios los interesados en conocerla, los demás son conocedores parciales, o Expertos parciales. Si nos basáramos simplemente en esto, el primer pensamiento es quien es el experto parcial le solicite los datos al experto total (pull). Pero he aquí que es donde entra a desempatar el patrón Bajo Acoplamiento: como no se trata de una única clase la interesada, entonces tendremos N clases fuertemente acopladas a esta Clase experta. El patrón Bajo Acomplamiento y Variaciones Protegidas sugiere que se busque reducir el impacto.
Se necesita de una comunicación entre ese grupo y el experto (el sujeto), de algún modo ¿Si tirando conseguimos más acoplamiento, entonces como le hacemos... el experto tiene la información y nosotros la queremos?. Entonces decimos que como el sujeto conoce la información, y a fin de evitar mayor acoplamiento con varias clases, es que en vez de recurrir a Pull's se estila Push. Entonces es así como las clases interesadas reciben el dato.

Al menos eso es lo que yo tengo entendido sobre Pull y Push. Dos técnicas que se recurren para enviar y recibir información.

Saludos,

[Delphius]

¿Alguna novedad? ¿Se entendió lo que comenté sobre Push/Pull, o estoy equivocado? 

Saludos,

[Rolphy Reyes]

¿Alguna novedad? ¿Se entendió lo que comenté sobre Push/Pull, o estoy equivocado? 

Saludos,

Saludos.

Sí amigo, se entendió perfectamente.  Solo que no tenía suficiente tiempo para responder.

He leído en reiteradas ocasiones los enlaces que expuse y tu idea expuesta, a mi modo de ver, ambos van por el mismo camino, salvo que el autor de los enlaces hace uso del patrón Observador para implementar estas técnicas.

Ahora bien aquí también mencionan dicha "tipificación". E incluso expresan que la mejor manera es la versión push:

Define an object that is the “keeper” of the data model and/or business logic (the Subject). Delegate all “view” functionality to decoupled and distinct Observer objects. Observers register themselves with the Subject as they are created. Whenever the Subject changes, it broadcasts to all registered Observers that it has changed, and each Observer queries the Subject for that subset of the Subject’s state that it is responsible for monitoring.

This allows the number and “type” of “view” objects to be configured dynamically, instead of being statically specified at compile-time.

The protocol described above specifies a “pull” interaction model. Instead of the Subject “pushing” what has changed to all Observers, each Observer is responsible for “pulling” its particular “window of interest” from the Subject. The “push” model compromises reuse, while the “pull” model is less efficient.

El autor de los enlaces expuestos anteriormente, en el segundo párrafo expresa algo como que al final sigue siendo un patrón  o por lo menos eso fue lo que capte.

Me parece mi estimado que tendremos que seguir documentandonos acerca de estas dos vertientes. 

[Delphius]

Así es amigo,
Como ya lo estás dimensionando, el tema es bastante amplio y hay muucho por descubrir, analizar, estudiar, debatir. 
Lo lindo y maravilloso es que una vez que lo vas estudiando y agarrandole la mano le empieza a adquirir gusto y hasta nos ponemos a unir ideas... por ejemplo yo me hacía preguntas como: ¿Puede darse el caso en que se necesite de una Estrategia Compuesta (Strategy + Composite) y que a su vez ésta sea una Fábrica Abstracta? ¿Cómo sería dicho diagrama? ¿Cuáles serían sus puntos de cohesión y acoplamiento y en que afectarían a la clase cliente? ¿Habrá otra posible alternativa?

Esos tipos de ejercicios mentales es lo que hizo cortocircuito en mi cabeza, ¡pero es que no lo podía evitar!¡Me entusiasmaba la idea!.

Es complicado llegar a una comprensión bastante completa acerca de los patrones. Imagínate... si con apenas unos pocas decenas de ellos (los básicos y escenciales) uno se hace un lío, ¿cómo será si llegásemos a estudiar los centenares que hay? 

Saludos,

[egostar]

Pues mientras tanto, yo me voy a poner a abstraer el concepto, después y con menos ignorancia podré entenderles

Salud OS

[Delphius]

Pues mientras tanto, yo me voy a poner a abstraer el concepto, después y con menos ignorancia podré entenderles

Salud OS

Pos, si te quieres empapar sobre el tema, comienza a leer UML y Patrones de Craig Larman. Y si no te jode el inglés este blog te será de ayuda. 

No te precoupes amigo, porque si tenemos que comparar ignorancia... ¡soy el campeón! Me preguntas de cualquier otra cosa que no sea de Ing. Sofware, UML, Patrones, alguito de Delphi, Firebird (que se muy poco), base de datos en general y POO y quedo en blanco. 

Saludos,

[egostar]

Pues mientras tanto, yo me voy a poner a abstraer el concepto, después y con menos ignorancia podré entenderles

Salud OS

Pos, si te quieres empapar sobre el tema, comienza a leer UML y Patrones de Craig Larman. Y si no te jode el inglés este blog te será de ayuda. 

No te precoupes amigo, porque si tenemos que comparar ignorancia... ¡soy el campeón! Me preguntas de cualquier otra cosa que no sea de Ing. Sofware, UML, Patrones, alguito de Delphi, Firebird (que se muy poco), base de datos en general y POO y quedo en blanco. 

Saludos,

Pues me estan dando ganas de comprar los videos (Why read if you can watch?), 50 dolares y te regalan dos libros del tema.... me parece que será mi próxima compra

Salud OS

[Rolphy Reyes]

Pues mientras tanto, yo me voy a poner a abstraer el concepto, después y con menos ignorancia podré entenderles

Salud OS

Pos, si te quieres empapar sobre el tema, comienza a leer UML y Patrones de Craig Larman. Y si no te jode el inglés este blog te será de ayuda. 

No te precoupes amigo, porque si tenemos que comparar ignorancia... ¡soy el campeón! Me preguntas de cualquier otra cosa que no sea de Ing. Sofware, UML, Patrones, alguito de Delphi, Firebird (que se muy poco), base de datos en general y POO y quedo en blanco. 

Saludos,

Pues me estan dando ganas de comprar los videos (Why read if you can watch?), 50 dolares y te regalan dos libros del tema.... me parece que será mi próxima compra

Salud OS

Eso esta en mi lista de deseos.... ya los comprare en su momento..