Discusión OOP: Un sistema de avisos, usado por varias clases

[[Delphius]]

Empezado por roman

Yo me permito insistir un poco en la nomeclatura. El hecho de haya facturas pendientes es una situación, no un aviso. Porque mientras persista dicha situación, el objeto fuente tendría que estar generando el mismo aviso, que es lo que no me cuadra.

Pues yo la verdad no entiendo si al final se trata de facturas pendientes... y/o si debemos entender por aviso otra cosa.
Hace falta claridad en las explicaciones de Bauhaus1975 sobre el contexto en forma intregral (macro) del problema y no en éstas simples clases.

Empezado por roman

Ahora, más allá de los términos exactos, creo que éste es un caso en donde las interfaces aplican muy bien. Una entidad agenda y una entidad facturas, en principio podrían no tener nada en común salvo el hecho de poder publicar una lista de pendientes. En este caso, derivar ambas de una clase común podria ser algo forzado y no natural para efectos de la aplicación.

Estaba pensando en ello también. Creo que el tener esta interfaz serviría, y además nos evitaría el tener que depender de alguna clase base.

Empezado por roman

A como veo las cosas, tiene que ser así. Porque el hecho de publicar un aviso no resuelve la tarea, es decir, la factura sigue pendiente por ejemplo, y desde luego, no puede ser el gestro de avisos quien cumplimente la operación, debe por fuerza ser la entidad que genera el aviso. Por ello es que aviso no es un término que me parezca adecuado.

Pues yo no puedo decir, ni asegurar que deba ser ser así. Hay cosas que no están bien claras.
Efectivamente, creo que debemos partir de este punto. ¿Qué debemos entender por aviso?

Además, me suena un tanto extraño de que entidades, un tanto dispares como ser TAgenda y Factura deban dar respuesta a una misma problemática. ¿Que és este TAgenda? ¿Qué es esta TFactura? ¿Qué tiene que ver citas, agendas y facturas? No se, pero no me gusta mucho mezclar citas con negocios.
Yo pido que Bauhaus1975 se explique apropiadamente.

Empezado por roman

Básicamente es lo que planteé con el método getListaPendientes de la interfaz IEntidad.

aunque esta parte no le veo necesidad. Cada IEntidad (o IPublicadorPendientes) se registra con el Gestor de manera que éste simpemente debe ciclar sobre la lista de registrados llamando al método getListaPendientes:

Código Delphi [-]for I := 0 to FEntidades.Count - 1 do begin FEntidades[i].getListaPendientes(...); end;


que básicamente sería lo que llamé EnumerarPendientes.

// Saludos

Eso noté luego. Tu idea me resulta mejor.

Saludos,

[[Delphius]]

Impresionante roman.
Cuando estaba respondiendo ví que habías puesto algo más concreto.

Me sorprende lo de pasar como parámetro el procedimiento. No se me hubiera ocurrido.

Hoy aprendo algo nuevo: desconocía TInterfaceList.

Saludos,

[roman]

Empezado por Delphius

Me sorprende lo de pasar como parámetro el procedimiento. No se me hubiera ocurrido.

Pues son de las cosas que te gustan. Si no me equivoco, no es más que el patrón Iterador (interno).

// Saludos

[[Delphius]]

Empezado por roman

Pues son de las cosas que te gustan. Si no me equivoco, no es más que el patrón Iterador (interno).

// Saludos

Había "escuchado" sobre ese patrón, pero no lo he estudiado. Más adelante le daré su debido tiempo de análisis y estudio y me documentaré al respecto.
Gracias por el dato.

Saludos,

[roman]

Empezado por Delphius

Además, me suena un tanto extraño de que entidades, un tanto dispares como ser TAgenda y Factura deban dar respuesta a una misma problemática. ¿Que és este TAgenda? ¿Qué es esta TFactura? ¿Qué tiene que ver citas, agendas y facturas?

Precisamente por eso viene lo de interfaces. Agendas, facturas y seguramente otras entidades del sistema del compañero, tiene poco a nada en común, salvo el hecho de notificar que hay tareas pendientes. Y es esta problemática la que resuelve la interfaz. No es que esas entidades deban dar respuesta a una misma problemática, sino que esta problemática es común (y quizá lo único común) a ellas.

// Saludos

[Bauhaus1975]

Muy buenas compañeros. Me alegra ver como ha crecido el interés en el post (y eso que había empezado flojo).
Es cierto, probablemente lo que nos parece bien explicado no se entienda por diferente uso de términos. Y sin duda, los nombres que tomé inicialmente eran demasiado genéricos.

Empezado por Delphius

Estaba pensando en ello también. Creo que el tener esta interfaz serviría, y además nos evitaría el tener que depender de alguna clase base.

Estupendo, me alegra que seas el primero que me de la razón en algo . Es broma, mi madre alguna vez ya lo hizo antes.

Empezado por Delphius

¿Qué debemos entender por aviso?

Hasta donde yo había pensado, una descripción y un enlace que pueda abrir un formulario para acceder al dato y poder cambiar esa situación.
Y como apunto más adelante una propiedad 'prioridad' = (urgente, normal)

Empezado por Delphius

Además, me suena un tanto extraño de que entidades, un tanto dispares como ser TAgenda y Factura deban dar respuesta a una misma problemática. ¿Que és este TAgenda? ¿Qué es esta TFactura? ¿Qué tiene que ver citas, agendas y facturas? No se, pero no me gusta mucho mezclar citas con negocios.
Yo pido que Bauhaus1975 se explique apropiadamente.

Nada que ver, evidentemente. Por eso Roman está acertado viendo lo conveniente de introducir una Interfaz que defina la funcionalidad necesaria para obtener el aviso. 'obtener' -> Aquí nos hemos creado confusión con el término. Cada entidad que quiera 'publicar' avisos debe implementar un método con sus propios criterios para obtener dichos elementos.
Es más, por eso he puesto así el ejemplo. Porque el sub-sistema que estamos definiendo quede aislado del contexto. Es decir, igual que hemos hablado de facturas y agenda podemos pensar en un artículo que se haya agotado y hay que pedirlo. (serviría a cualquier proyecto con entidades suceptibles de generar 'pendientes')

Otra cosa, como apuntais: No todos los avisos son iguales. Me explico, a lo mejor es bueno mostrar 'de vez en cuando' en la ventana de avisos los artículos que faltan, pero a lo mejor en cuanto a las facturas pendientes de pago es suficiente con que aparezcan al iniciarse el programa.
Por tanto puede que el objeto que represente a un item 'aviso' tenga 'prioridad' = (urgente, normal) prioridad normal podría ser sólo para mostrar en la ventana al iniciarse el programa, y urgente para mostrar periódicamente.

He leido detenidamente el análisis de Roman y me parece lo más acertado. Y, el uso del InterfaceList y el paso del procedimiento como parámetro impresionante ejemplo de elegancia.

Entonces podemos resumir las clases y sus responsabilidades:

TPendiente: representa a un item. con elementos como (prioridad, fuente, descripcion)
IPublicador: La interfaz que define el método para obtener los pendientes de clase con getListaPendientes(Lista: TList);
TGestorPendientes: Se encarga de ofrecer el registro a las clases que quieran publicar, y de enumerar los items a publicar
TPublicarPendiente: Un tipo procedimiento para que la acción 'publicar' sea cualquier cosa que implemente una clase encargada del tema gráfico u otros.

Podría quedar por sacar punta a como añadir la acción de abrir formulario de la entidad a la que se refiera el item (TPendiente)

Para el tema de controlar avisos de alta prioridad se puede incorporar un sistema de control periódico, si no recuerdo mal esto se ha tratado antes en otros post. (Abajo en la lista de relacionados puede verse algún ejemplo)

Espero que este laborioso estudio ofrezca información de este sistema y muchos compañeros puedan implementarlo cuando les haga falta. Yo estoy ya deseando de implementarlo, a ver si puedo sacar hueco porque estoy con varias cosas a la vez.

Un saludo.

[roman]

Empezado por Bauhaus1975

Esto, en realidad, lo dijo Delphius.

Empezado por Bauhaus1975

Podría quedar por sacar punta a como añadir la acción de abrir formulario de la entidad a la que se refiera el item (TPendiente)

La clase TPendiente puede tener una propiedad que apunte al formulario deseado.

Por otra parte estaba pensando que una ampliación que puede hacerse es la de incluir al gestor de mensajes en la interfaz IPublicador con objeto de que cada publicador pueda notificar al gestor cuando hay algún cambio en su lista de pendientes.

// Saludos

[Bauhaus1975]

Empezado por roman

Esto, en realidad, lo dijo Delphius.



La clase TPendiente puede tener una propiedad que apunte al formulario deseado.

Por otra parte estaba pensando que una ampliación que puede hacerse es la de incluir al gestor de mensajes en la interfaz IPublicador con objeto de que cada publicador pueda notificar al gestor cuando hay algún cambio en su lista de pendientes.

// Saludos

Perdón, lo rectifico ahora mismo.