¿Patrón de observador o devolución de llamada?

Question

que tengo que hacer un diseño de una DownloadManager, pero mi pregunta principal está relacionada con las notificaciones que un Download pueden enviar a la DownloadManager como onUpdate() para actualizar una barra de progreso, onError(), onFinish(), etc. De alguna manera el DownloadManager tiene que recibir este notificaciones de su Download s.

he pensado 2 maneras posibles:

• patrón de observador
• devoluciones de llamada

patrón Observer

Básicamente hay 1 Observadores observable y N. En mi caso, el DownloadManager tiene que ser un Observer y las Descargas los Observables, por lo que la relación es N Observables 1 Observer, todo lo contrario.

La ventaja es centralizar todas las notificaciones posibles en un método, el notify() o el update() (de Java) método de los observadores, en mi caso solo el DownloadManager. Puedo pasar un parámetro al método notify() con el código de la notificación.

¿Desventaja? Estoy usando un patrón de oop para algo que se puede hacer fácilmente con una devolución de llamada. Además, N observa que un observador es algo raro, al menos con el patrón del observador porque este patrón se realizó para 1 observador observable de N, por lo que realmente no usaré el patrón del observador.

devolución de llamada

muy similar al patrón de observador. DownloadManager implementa un "oyente" (interfaz). Este oyente implementa las funciones de notificación en Finish(), onUpdate(), etc. Luego, este listener debe estar registrado en todas las descargas, de modo que cuando finalice una descarga, llame al listener.onFinish(). Además, puedo pasar parámetros a este método desde Descargas, como en el patrón de observador.

Ventaja: Fácil de usar. Desventaja: ninguna.

Probablemente usaré una devolución de llamada porque, en mi opinión, no tiene sentido utilizar un patrón de observador para 1 observador N observables.

Y usted, ¿qué opción utilizará?

Answer 1

Devolución de llamada FTW. Es más simple, y en la gran mayoría de los casos, la simplicidad influye en todos los demás aspectos del proyecto de forma positiva, incluido el desarrollo, la depuración, la optimización, la documentación y el mantenimiento adicional.

Answer 2

El observador es más flexible/escalable. No es tan extraño después de todo el uso que mencionaste para el patrón del observador. Los patrones son, después de todo, solo guías, si necesitas cambiarlo un poco para que se ajuste a tus necesidades, entonces ve a por él.

Considere el caso cuando tiene múltiples DownloadManagers (quizás este no es un caso de uso válido para su situación particular). Deberá registrarlos a ambos. Si tiene aún más, tendrá que registrarlos todos.Lista bastante larga, además de que necesita implementar la administración de oyentes en el Download s

Answer 3

También hay una opción, que es opuesta al enfoque Observador/Devolución de llamada. Puede convertir clientes de DownloadManager pasivos a jugadores activos del programa. En lugar de esperar un mensaje del administrador, solicitarán regularmente su estado.

De esta manera, su proceso de descarga se verá mucho más suave para el usuario final. Y podrás controlarlo mejor.

Por supuesto, tendrá que usar dos hilos. O tendrá que enseñarle al DownloadManager a trabajar en pequeños pasos, devolviendo el control a su cliente, en lugar de ejecutar un trabajo irrompible.

Answer 4

observador es más adecuado porque el administrador necesita enviar solicitudes a muchas instancias.

Es fácil de implementar. En el punto de implementación será más escalable en cuanto a la funcionalidad de la barra de progreso y cuánto se descargó cada uno y Total% Descargar