I have to do a design of a DownloadManager
, but my main question is related to the notifications that a Download
can send to the DownloadManager<
observer is more suitable because Manager need to send request to many instances.
It is easy to implement. In implementation point of it will be more scalable in terms of progress bar functionality and how much downloaded each one and Total % Download
Callbacks FTW. It is simpler, and in the vast majority of cases, simplicity influences every other aspect of the project in a positive way, including development, debugging, optimization, documentation and further maintenance.
The observer is more flexible/scalable. Is not that weird after all the usage you mentioned for the observer pattern. Patters are after all just guidlines, if you need to change it a bit to fit your needs then go for it.
Consider the case when you have multiple DownloadManagers
(maybe this is not a valid use case for your particular situation). You will need to register both of them. If you have even more then you will have to register all of them. Pretty long list, plus you need to implement listeners management in the Download
s
There is also one option, which is opposite to Observer/Callback approach. You can turn clients of DownloadManager
from passive to active players of the show. Instead of waiting for a message from the manager they will regularly request its status.
This way your download process will look much smoother to the end-user. And you will be able to control it better.
Of course, you will have to use two threads. Or you will have to teach the DownloadManager
to work in small steps, returning control to its client, instead of running one unbreakable piece of work.