Observerpattern ist natürlich eine Antwort:
Variante 1 (Observer-Pattern): Deine Klassen 'A' und 'B' sagen 'X': "Ich hab mich geändert". 'A' und 'B' wären ISubject und 'X' der IObserver.
Variante 2: Du implementierst einen 'Controller'. 'X' meldet sich beim Controller an und sagt dem 'Wenn dir jemand sagt:'Hab mich verändert', sag mir Bescheid'. 'A' und 'B' kennen den Controller und sagen dem 'Hab mich verändert', wenn sich etwas verändert hat.
Der Vorteil von #1 ist die unmittelbare Umsetzung, d.h. wenn Du sowas sonst nicht brauchst, dann ist das ein Dreizeiler. (X implementiert einfach eine Methode, die A und B aufrufen). Nachteil: Wenn 'X' nicht instantiiert ist, haben wir ein Problem, denn A und B benötigen ja eine Instanz von 'X'. Noch ein Nachteil: Wenn man das öfter implementiert, hat man redundanten Aufwand und keine zentrale Kontrolle, wer mit wem spricht (braucht man manchmal).
Der Vorteil von #2 ist sehr hohe Flexibilität und Erweiterung: Z.b. könnte sich jemand zum Debuggen an die Benachrichtigung anhängen. Der Controller sagt dann nicht nur 'X' Bescheid, sondern auch der zweiten Instanz. Der größte Vorteil ist aber, das sich alle nur mit dem Controller reden, also A und B von X keine Kenntnis haben müssen, d.h. A und B können immer mitteilen 'Hab mich verändert', auch wenn es 'X' gar nicht gibt. Der Nachteil ist ein erhöhter Umsetzungsaufwand, weil der Controller ja geschrieben werden muss. Aber schlimm ist das nicht.
Ach, und dann gibt es ja noch Messages. Du kannst einfach
Deine Klassen mit einem Messagehandler ausstatten und auf Messages reagieren.
Ich würde mich mit #1 und #2 beschäftigen und -je nach Anforderung- eins von beiden Umsetzen.