nicht angemeldet
Hi,
Im Grunde geht es darum, ein modular aufgebautes Programm zu erstellen, bei dem die eigentlich arbeitenden Teile weitgehend von den Bedien- und Anzeigeelementen getrennt sind.
"Weitgehend" sollte das Stichwort sein - nicht *zu* weit.
Beispiel Taschenrechner: Die Recheneinheit hat etwas ausgerechnet und das Ergebnis steht in einer Eigenschaft namens "ergebnis". Natürlich soll das Ergebnis auch angezeigt werden. Anstatt jetzt im Rechnermodul zu notieren
anzeigeModul.ergebnisElement.value = this.ergebnis;
> löst man nur einen Event namens "Ergebnis\_fertig" aus.
Aber wenn es den Event einfach nur in die Luft bläst, ohne dass ihn irgend jemand zur Kenntnis nimmt, hat keiner was davon.
Das Anzeigemodul muss sich auch "zuständig" fühlen - also kommst du m.E. nicht darum herum, die beiden miteinander bekannt zu machen.
Bleiben wir beim einfachen Taschenrechner-Beispiel:
Beim erzeugen eines neuen Taschenrechner-Objektes kannst du doch eine Methode eines konkreten Anzeigemodul-Objektes per Referenz übergeben - diese Methode ist (später, immer wieder) aufzurufen, wenn das Taschenrechner-Objekt etwas ausgerechnet hat. Dabei ist dieses Ergebnis als Parameter zu übergeben.
Das sollte doch ausreichend flexibel sein. Das Anzeigemodul kann aus was immer es möchte bestehen, kann mit dem Ergebnis machen, was es möchte - als Text anzeigen, eine Grafik erstellen, in ein Cookie speichern, etc.
\*Alles\*, was den Taschenrechner von ihm interessiert ist, dass ihm eine Methode benannt wurde, der er sein Ergebnis zu übergeben hat, fertig.
> Das Rechnermodul kennt nämlich das "anzeigemodul" gar nicht, und weiß natürlich auch nicht, dass es dort ein "ergebniselement" (DOM-Element) gibt.
Das "Ergebniselement" interessiert den Taschenrechner überhaupt nicht.
Er hat über eine definierte Schnittstelle (Methode einer konkreten Objektinstanz) sein Ergebnis übergeben - alles, was danach mit diesem gemacht wird, ist für ihn uninteressant.
> Sondern es funktioniert umgekehrt: Das "ergebniselement" im Anzeigemodul holt einfach bei Bedarf das Ergebnis vom Rechnermodul ab, sobald es zur Verfügung steht, d.h. wenn der Event gefeuert ist.
Warum soll das Anzeigemodul irgendetwas "abholen"?
Das Anzeigemodul sehe ich hier als "Empfänger" - es bekommt etwas übergeben, und führt damit seinen Teil der Aufgabe, nämlich es irgendwo irgendwie darzustellen, aus.
> Der entsprechende Eventhandler weiß von der Eigenschaft "rechnermodul.ergebnis" und führt einfach
> `this.value = rechnermodul.ergebnis;`{:.language-javascript}
> aus.
Wenn du "Eventhandler" hier durch Methode des Anzeigemoduls ersetzt, dann "fehlt" doch eigentlich gar nichts mehr.
Das ist im Rahmen von OO alles gut abbildbar, wenn man die Elemente in dem minimalen Rahmen "miteinander bekannt macht", den ich oben skizziert habe.
Das Anzeigemodul braucht noch nicht mal unbedingt das Taschenrechner-Objekt zu kennen; es könnte auch die Ergebnisse mehrerer Taschenrechner darstellen, wenn das gewünscht wäre.
Lediglich der Taschenrechner ist hier der jenige, der ein Anzeigemodul kennen "muss" - er ist der jenige, der etwas berechnet hat, das er jetzt irgendwie "loswerden" möchte; damit sich jemand anderes um die Darstellung/Auswertung/Speicherung/sonstwas kümmert.
Es geht hier im Grunde lediglich um Interaktion/Datenaustausch zwischen Objekten.
Eine Notwendigkeit, das über "Events" zu realisieren, sehe ich aber nicht.
Im DOM \*hast\* du eine Beziehung zwischen Elementen - sie sind Vor- oder Nachfahren von anderen; das ist in dem Umfeld das Maß, in dem sich die Elemente "kennen". Und zwischen denen können dann Events auf- und absteigen, bis sich irgend jemand in der Kette für zuständig befindet.
Diese Beziehung zwischen Elementen, die im DOM nahezu "natürlich" vorhanden ist, hast du beim Taschenrechner/Anzeigemodul erst mal nicht - also musst du sie irgendwie herstellen. Und genau dagegen scheinst du dich im Moment ein bisschen zu sträuben, und anzunehmen, dass "Events" dir diese Herstellung eines Bezugs zwischen den Objekten abnehmen würden oder könnten - tun sie m.E. aber nicht.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.