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.
Cita:
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.
Cita:
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)
Cita:
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.