# FAQ zu Kapitel 22 Einführung in Entwurfsmuster

Viele Entwurfsmuster verbinden mehrere Objekte oder Klassen. Wie nennt man diese Gruppierungen und wie beschreibt man ihre Interaktion?

* Man nennt sie *Teams*. Ein Team enthält Spieler, die miteinander in einem Szenario interagieren, um ein gemeinsames Ziel zu erreichen. (www.objectteams.org)
* Die Interaktionen des Szenarios nennt man die *Kollaboration* des Teams. Eine Kollaboration in UML kann durch ein Sequenzdiagramm oder anderes Interaktionsdiagramm beschrieben werden. 

### Composite Muster

* Was ist ein Composite im Entwurfsmuster MVC?
  * Das Composite Muster wurde bereits in Kap 13 erklärt, als wir die Hierarchie der Testsuiten und -fälle in jUnit erklärten. Es hat 3 Hauptklassen: Schnittstelle Kompositum, von der Leaf und Composite erben (i.d.R. abstrakte Klassen). 
    * Leaf beschreibt atomare Knoten im Baum
    * Composite beschreibt komposite Knoten (z.B. Testsuites oder Widgets)
  * Viele Widget-Elemente der GUIs (graphische user interfaces) sind komposit strukturiert, z.B. Libreoffice besteht aus mehreren Unterfenstern mit hierarchischen oder list-baren Informationen (Folienliste, Farbenliste, Galerie, etc.) 
  * Views im MVC können durch Composite in Hierarchien gegliedert sein (sog. "widget trees")
  * Rekursive Algorithmen gehen einfach zu spezifizieren, weil die Schnittstelle "Kompositum" davon abstrahiert, ob ein Leaf oder ein Composite vorhanden ist. "Map" auf einen Baum durchzuführen, also einen Algorithmus auf alle Knoten anzuwenden, ist sehr einfach.

### Observer

* Warum muss Observer den Daten-pull vom der Notification (notify) trennen?
  * Weil die Daten, die transportiert werden müssen, groß sein können (MB). Wenn direkt transferiert wird (push-Observer, siehe Kapitel 24), dann wird die Notifikation anderer Observer verzögert.
  * Wenn die Observer auf verschiedenen Cores liegen oder anderen Rechnern, werden sie in ihrer Parallelität eingeschränkt.

### MVC Muster

* Warum sollte MVC so stark aufgeteilt werden?
  * Die Liste der Views muss erweiterbar sein. 
  * Der Controller kann steuern, wann und wie Daten hin- und herbewegt werden. 
  * Das (Daten-)Modell muss die Sichten nicht kennen, sondern nur den Controller, der dann die Sichten als Observer kennt. 
* Model MVC: Können mehrere Views a) gleichzeitig editieren und wenn ja, b) wie werden Hazards (Lese-Schreibkonflikte) vermieden/gelöst?
  * a) Ja. In Java werden "Model"-Objekte sequentiell mit den Views gekoppelt, sodass  gleichzeitige Edits sequentialisiert werden. Nutzt man Java threads, muss man die "Modellobjekte" schützen, z.B durch "synchronized" Methoden oder Semaphore. 
  * b) In parallelen Programmen braucht man "geschützte Datenstrukturen", um die Konflikte zu vermeiden. 
* Warum ist beim MVC zwischen View und Model eine Linie eingezeichnet? Ist der Sinn nicht, dass jegliche Kommunikation über den Controller abläuft?
* In einigen Varianten des Musters gibt es keine Linie, da läuft ale Kommunikation über den Controller. 
  * Wir behandeln im Kapitel "GUI Architektur" (Kap. 43) die Variante  "Passive View" von Martin Fowler, die ausschließlich den Controller benutzt. 
  * Das Original-Muster aus Gamma erlaubt die Linie, damit das View das Modellobjekt beschreiben kann (Edits, "play-in"). Der Observer läuft zur Ausgabe an die Views ("play-out") 
* Wie würde denn ein Diagramm ähnlich zu Folie 18 zu MVVM (Model-View-ViewModel) aussehen (z. B. SwiftUI/React)?
  * Die Vorlesung 43 beachten: "Passive View"