Designfrage zu Anwendung mit untersch. Steuerung

hallo,
ich verzweifle an Designüberlegungen einer Anwendung, die ich gerade privat so am Basteln bin.
Es ist ein "Music-Player". Ziel ist es eigentlich, diesen bei PC Start zu starten und dann durch einen Controller der am PC hängt oder eine Fernbedieung zu steuern. Aber auch eine GUI soll möglich sein.
Ich habe mir überlegt dass ich ein Interface IPlayerController habe, das alle Steuerungsmöglichkeiten implementieren müssen. Damit nichts blockiert muss ich alle IPlayerController eigentlich in nem eigenen Thread haben (hmm bei der GUI schwierig).
Dann gibt es die Hauptkomponente, die die Musik spielt.
Ich habe Probleme damit, das ganze schön zu verbinden. Wer kennt nun wen, ggf. über wen und wie kommunizieren Controller und Player (Events oder Funktionen)?
Mein aktueller Ansatz ist der, dass es einen "Manager" gibt, der kennt alle Controller und den Player, und die Controller kommunizieren über Events mit dem Manager, der steuert den Player über Funktionen (Play, Pause, Lauter, etc.). Ist das gut so, oder gibts ne bessere Lösung?
Und wie handhabe ich die Steuerung über GUI als extra Thread?
Prinzipiell müsste der Manager die GUI wie alle anderen Controller als extra Thread starten, andererseits liest man überall die GUI darf nie in nen anderen Thread ausgelagert werden...ist das hier ne Ausnahme (der Manager weiß ja auch garnicht dass es eine GUI ist, er kennt ja nur das Interface)? Die GUI ist ja nichts zentrales, sondern nur eine andere, alternative Möglichkeit, um den Player zu steuern.
Alternative wäre dass ich immer die GUI habe und nur die anderen Controller als Threads parallel dazu erlaube...aber dann wäre die GUI nicht einfach austauschbar.

Ich hoffe ihr habt etwas Input/Tipps für mich
gruß & thx
sth_Weird

Ich würde kein interface für die steuerungen ansich machen, sondern eher eins, dass alle aktionen anbietet, die von den guis benutzt werden können. Man kann aber natürlich genausogut ne klasse dafür nehmen. Dann kann jede gui einen verweis auf ein und das selbe objekt haben, dass dann mit locks synchronisiert, im lock fehleingaben abfängt und die aktion ausführt. also dein manager. der muss die guis ja aber ned kennen. den manager kann man bei bedarf von marshalbyrefobjekt ableiten.

Also das übliche.

Hallo sth_Weird,

Ich habe mir überlegt dass ich ein Interface IPlayerController habe, das alle Steuerungsmöglichkeiten implementieren müssen. [...]
Dann gibt es die Hauptkomponente, die die Musik spielt.

ich glaube, du vermischt bei deinem Ansatz eine Art Mehrschichtenarchitektur (Logik und View) mit dem MVC-Pattern (View wird durch Model, View und Controller dargestellt).

Die Idee mit der "Hauptkomponente" ist aber schon nicht schlecht; Basis deiner Anwendung könnte z.B. eine Klasse Player bilden:

public interface IPlayer
{
    int MillisecondsPlayed
    {
         get;
    }
    
    event EventHandler PlayStateChanged;

    void Play(ISong song);
    void Stop();
}

Hierbei könnte PlayStateChanged immer gefeuert werden, wenn sich etwas ändert (z.B. aktueller Song, Stop aufgerufen wurde etc.), aber nicht unbedingt, wenn sich MillisecondsPlayed ändert - das ist ja ständig der Fall.

Deine "Fernbedienungsvariante" könnte nun diese Klasse verwenden und die Befehle größtenteils durchreichen.
Der Player selbst würde (je nach Technologie) evtl. einen zweiten Thread für das Abspielen eröffnen, sodass Play sofort zurückkehrt.
Einen separaten "Manager" brauchst du da dann eigentlich nicht.

Die GUI-Variante würde auch diesen Player verwenden (dieser würde ja auch die Hauptlogik enthalten).
Allerdings könnte diese ja dann z.B. in einem MVP-Ansatz wiederrum aus mehreren Verantwortlichen bestehen.

Und wie handhabe ich die Steuerung über GUI als extra Thread?

Die GUI würde (direkt oder indirekt über einen Presenter) auf PlayStateChanged reagieren und zusätzlich z.B. alle 100ms den Fortschrittsbalken aktualisieren.
Der Player wüsste nichts davon, dass der in einem anderen Thread läuft, das macht alles die GUI.

Auf diese Weise könnte sich auch die Fernbedienungsvariante und der Presenter der GUI den Player teilen.

Wenn sich der Player eh immer beim Hochfahren starten soll, aber die GUI evtl. garnicht, dann würde ich eher den Player als Daemon machen und die ganze Steuerung über IPC (Interprozesskommunikation) lösen. Das macht dann auch das Tauschen der einzelnen Komponenten (PlayerDaemon, GUI, RemoteService) einfacher.