[nooneonearth]

Deine Frage beantwortet sich fast schon in ihrer Stellung:

• Variante 1 benötigt deutlich weniger Code als Variante 2.
  
• Variante 1 verbirgt den Thread-Code; wenn es lediglich darum geht, den Download zu starten und bei der Beendigung benachrichtigt zu werden, dann braucht es nicht viel mehr.
  
• Bei Variante 2 hat man die Freiheit selbst steuern zu können, ob man den Download synchron oder asynchron ablaufen lassen möchte. Um das zu bewerkstelligen, braucht es wahrscheinlich zusätzlich zum Event noch eine Methode zum Abrufen des Ergebnisses. Allerdings kann auch durch Wegkapseln dieser Details (etwa mit einem Boolean-Parameter async) diese Freiheit gelassen werden.
  
• Sollen die Download-Threads explizit gesteuert werden, könnten, bei Realisierung von Variante 1, die entsprechenden zu kapselnden Steuermethoden die Klasse unübersichtlich machen - sie macht zu viel. Im Moment fällt mir dazu jedoch nichts Geeignetes ein. Ich sehe etwa eine Methode zum Abbrechen des Downloads, Events zum Status des Downloads (Fortschritt, Beendet) und eine Methode zum Abrufen der heruntergeladenen Daten. Dabei ist das Abbrechen und die Benachrichtigung ohnehin nur bei asynchronen Konzepten sinnvoll, da in einer single-threaded Anwendung der Hauptthread blockiert wird, bis der Download beendet ist.
  
• Am Ende wirst du für deine Klassenbibliothek zwecks effizienter Ressourcenverwaltung (Threads, parallele Downloads) wahrscheinlich darin enden, dass du einen Download-Manager baust, dem du Jobs geben kannst, die er dann abarbeitet und dich bei Beendigung benachrichtigt. Eine Download-Manager-Komponente könnte man dann vielleicht sogar im Designer auf ein Formular ziehen o.Ä.

Schlussendlich macht es wohl Sinn, alles wegzukapseln.

Ich hoffe, das hilft.
Grüße