Ok, ich würde das über Observer angehen.
Listboxen können sich z.B. bei einer PKW-Liste registrieren.
Wird etwas in der Liste geändert, werden alle Beobachter informiert und werden sich daraufhin neu zeichnen.
Die Einträge einer Liste wiederum können sich als Beobachter bei einem Datenobjekt eintragen.
Eine Detailview kann sich bei einer Liste anmelden und wird informiert, wenn sich ihr aktueller Eintrag verändert.
Die View kann sich dann das aktuelle Objekt von der Liste abrufen (es muss nicht die ID sein, weil ja ohnehin dort ein Objekt vorliegt) und seinen Inhalt neu zeichnen.
Wird dort ein Wert des Datenobjektes geändert, muss das nicht die View an die Listbox melden weil ja die Listboxitems schon ihr Datenobjekt beobachten und sich bei Änderungsinformationen ohnehin neu zeichnen.
Also müssen i.d.R. die Controls untereinander kaum kommunizieren (außer die Meldung einer Liste an angemeldete Views bei einem Recordwechsel, da die aktuell ausgewählte Recordzeile nichts im Datenmodell zu suchen hat).
Ob Du Die Observerliste über Interfaces oder Objekte (vielleicht mit gemeinsamen Basisklassen) organisierst ist Geschmacksache.
Ich würde jedenfalls die gegenseitige Abhängigkeit der Controls möglichst gering halten.
NACHTRAG:
Umgekehrt muss Detail aber auch mit Master kommunizieren:
Detail sagt Master : Neues Element mit ID abc Status:blau und Text: Wupti eingefügt.
Wenn Du in der Detailview einen Eintrag hinzufügen oder löschen willst, dann muss diese View auch die ObjektListe von der Listbox abrufen. Sie muss aber dann nicht die Listbox informieren, wenn Sie ein Add oder Delete ausführt, da die Liste selbst ihre Beobachter über Änderungen informiert. Ok, für die nachträgliche Synchronisation des aktuellen Records kann eine Abstimmung Sinn machen.
Aber über die Beobachterliste kann man ja alle Interessenten anschauen und entscheiden, welche Informationen diese erhalten sollen.
Interfaces muss man hierbei nicht verwenden. Es bringt ein paar Vorteile, aber auch mehr Aufwand.