Oje wird sich so mancher Leser denken – ein sehr spezifischer Artikel. Ich habe vor eine programmierspezifische Artikelreihe durchzuziehen, weil ich mich gerde intensiv mit dieser Thematik beschäftige. Es geht um Design Patterns.
Im wesentlichen handelt es sich bei Design Patterns um programmiertechnische Vorschläge, wie Klassen und Objekte zu strukturieren sind, um spezielle Probleme effektiv zu lösen. Im ersten Teil der Serie widmen wir uns dem Observer Pattern.
Observer Pattern – Wenn sich bei mir was ändert, sollen andere drüber informiert werden
Worum gehts? Ein Subjekt hält einige Daten. Wenn sich bei diesen Daten etwas ändert, werden so genannte Observer darüber informiert und diese holen sich die neuen Werte. Diese Observer mussten sich jedoch vorher beim Subjekt anmelden, damit dieses auch weiß, wen es alles informieren muss. Das Subjekt und die Observer sind durch eine one-to-many Beziehung miteinander verknüpft.
Etwas spezifischer: Für das Subjekt wie für die Observer gibt es eine Interfaceklasse, in der abstrakte Methoden aufgeführt sind. Somit weiß, der Observer auf welche Methoden er im Subjekt zurückgreifen kann und das Subjekt weiß, wie es auf die Observer Objekte zugreifen kann. Und das ganz unabhängig davon wie die Subjekt-Klasse ansonsten aussieht.
Zur besseren Veranschaulichung betrachtet dieses UML-Klassendiagramm: