Damit ein Aggregationsobjekt vernünftig funktioniert muss es selber aber Funktionen bereit stellen um Daten/Anfragen für das gehaltenen Objekt anzunehmen, oder die Möglichkeit Objekte "abzugeben" und "anzunehmen".

Am Beispiel eines Objekts "Auto" das einen "Fahrer" hat. Will nun das Objekt "Polizist" mit "Fahrer" kommunizieren, gibt es nun drei Möglichkeiten.
A. "Auto" übergibt "Polizist" eine Referenz auf "Fahrer"
B. "Auto" übergibt "Fahrer" an komplett "Polizist" und dieser gibt "Fahrer" wider zurück an "Auto" wenn es fertig ist.
C. "Auto" stellt alle nötigen Funktionen breit die auch "Fahrer" hat und "Polizist" kommuniziert darüber.

B und C sind die bevorzugten Möglichkeiten in einer Multiprozessumgebung. Aber A ist das einfachste und funktioniert problemlos in einer Einzelprozessumgebung. Weshalb es auch die meiste Verwenung findet.

B/C machen aber enorme Arbeit z.B bei Objekten die zwei völlig unterschiedliche Schnittstellen anbieten.
Konverter z.B die Datenformate ändern. Ein/Ausgabe ist völlig getrennt. Einfach wäre es, wenn das schreibende Objekt und das lesende Objekt jeweils den Konverter kennen.
Will man es ordentlich machen, so muss das schreibende Objekt den Konverter anfordern, die Daten schreiben dann das Objekt zurück geben welches dann an das lesende Objekt übergeben wird.
Da werden aus zwei Zeilen Code gerne 30 mit jeder Menge getter/setter.

Mit Locking zu arbeiten macht da teilweise einfach mehr Freude, weil man den ganzen Verwaltungscode unsichtbar im Hintergrund machen kann. Nachteil ist das man unter Umständen Prozess-Zeit verschwendet wenn zu viel Code auf anderen Code warten muss. Zudem ist es nicht trivial alle Zugriffs-Regeln korrekt zu definieren und umzusetzen.
Last edited: 2017-07-20 18:57:07 +0200 (CEST)