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.
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.
Cita:
|
Empezado por Delphius
Un enfoque similar, habría que determinar cual es el más conveniente, es que el TGestorAviso no maneje la lista, sino que cada PublicadorAviso maneje la propia
|
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.
Cita:
|
Empezado por Delphius
En este caso, tal vez TGestorAviso disponga de métodos como ObtenerPendientes()
|
Básicamente es lo que planteé con el método getListaPendientes de la interfaz IEntidad.
Cita:
|
Empezado por Delphius
y reciba como parámetro un TPublicadorAviso
|
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