nicht angemeldet
Hallo,
Der Absender muss den Brief nicht persönlich im Kasten des Empfängers deponieren, sondern wirft ihn einfach in den nächstbesten von der Post.
Das ändert aber noch nichts daran, dass der Absender den Empfänger "kennen" muss - denn wenn du dessen Namen und Adresse nicht auf den Umschlag schreibst, dann wird die gute alte Post Schwierigkeiten haben, ihn zuzustellen.
Nicht unbedingt. Wenn ich nur draufschreibe "An den deutschen Bundestag", dann kommt der Brief möglicherweise trotzdem an, selbst wenn ich glaube, dass der vielleicht noch in Bonn tagt.
Gut, also ein Event newLetterRecieved tritt ein - und zwar beim Empfänger, bzw. dessen Briefkasten (ersterer "kennt" zweiteren hoffentlich).
Der Empfänger den Briefkasten? Ja, letzterer ist ja eine Methode von ersterem (sein Eventhandler).
Der Handler für diesen Event wäre aber noch wie vor bei Empfänger bzw. Briefkasten zu definieren.
Das ist richtig. Er muss einmalig für jeden Empfänger hardcodiert werden bzw. mindestens in einer Schleife zugewiesen werden. Das kann beim initialisieren eines Moduls geschehen, wo noch nichts zeitkritisches passiert.
Nehmen wir an, die Methode Empfaenger.checkYourMail wäre dafür aufzurufen.
Wenn es keinen Event gibt, den wir feuern könnten, dann müssen wir sie beim einfliefern des Briefes halt selber aufrufen.
Ob das jetzt du als Absender des Briefes, oder der Postbote als Zusteller macht, ist unerheblich.
Ist es nicht. Als Absender müsste ich die genaue Adresse kennen zum Aufrufen. Ein Feldwebel geht ja auch nicht zu jedem einzelnen Soldaten und aktiviert dessen Methode "lausche.auf(Befehl)", sondern er brüllt einfach in die Runde.
Auf jeden Fall muss jemand die Instanz Empfaenger kennen. Denn wenn nicht, und wir würden einfach einen Event everybodyCheckYourMail feuern - dann würden alle potentiellen Empfänger zum Briefkasten rennen (also jeder, der einen Briefkasten hat) - und alle bis auf den einen, der tatsächlich gerade einen Brief bekommen hat, würden dies umsonst tun.
Das stimmt allerdings. Wenn die Hierarchie nicht zu verzweigt ist, dürfte das aber kein Problem sein. Sobald angekommen, kann man ja mit stopPropagation (oder so ähnlich) die unnötige Weiterverbreitung abstellen.
Bleiben wir beim einfachen Taschenrechner-Beispiel:
[...]
Das ist eben nicht immer einfach. Während der Rechner noch rechnet, will er z.B. keine weiteren Eingaben engegennehmen, also müssen alle Bedienelemente des Eingabemoduls inzwischen deaktiviert sein.Sie müssen entweder beim Rechner anfragen, ob er schon wieder bereit ist, neue Eingaben anzunehmen;
Ein Klickbuttton soll ständig beim Rechner fragen, ob der wieder bereit ist? Womöglich mit setInterval oder so?
oder der Rechner muss ihnen Bescheid sagen, dass er es jetzt wieder ist.
Genau, aber er brüllt es nur in die Runde und sagt es nicht jedem einzelnen. Auch sagt er es nicht einfach dem Anzeigemodul, welches dann wieder zu jedem einzelnen rennen und es ihm ins Ohr flüstern müsste.
Wenn man nun statt dessen jedem betreffenden Bedienelement einen Event mit sprechendem Namen zuordnet, z.B. "calculation" (=es wird gerade gerechnet)
Der wäre auf dem Bedienelement m.E. fehl am Platze - das Taschenrechner-Objekt selber ist es, das Berechnungen durchführt.
Sicher, aber die Eingabeelemente müssen doch davon wissen.
und einen weiteren wie "inputReady" (=es darf eingegeben werden), dann können diese sich selbst aktivieren/deaktivieren,
Nein, können sie nicht.
Sie müssen vom Taschenrechner "benachrichtigt" werden, wenn dieser mit der Berechnung fertig ist.
Sag' ich doch, aber nicht *einzeln* vom Rechner direkt, sondern über einen Event, quasi ein gebrüllter Befehl vom Oberst. Den kann aber auch ein Oberfeld brüllen, das ist unerheblich; verstanden wird er in jedem Fall, und der Brüllende muss nicht jeden Soldaten beim Vornamen kennen.
Und woher wissen jetzt "alle" vorhandenen Bedienelemente (die ggf. zu ganz anderen Taschenrechner-Objekten gehören), ob sie sich von diesem "Event", der einfach ziellos in die Gegend gefeuert wird, angesprochen fühlen sollen oder nicht?
Naja, jeder Event ist doch eindeutig. Ein mouseover z.B. ist halt ein mouseover, und kein click. Ein selbstdefinierter inputReady ist ein inputReady, und kein fckYourself. Wenn ein entsprechender eventhandler "attached" ist, dann ist er zuständig, sonst eben nicht.
Dazu müssten sie selber wieder wissen, zu welchem Objekt sie eigentlich gehören.
Das aktuell zuständige Objekt kennen sie natürlich, falls nötig. Nur zum sich Aktivieren/Deaktivieren beispielsweise müssen sie es nicht kennen. Wenn der Feldwebel aber etwas brüllt wie "Erobern!", dann müssen sie natürlich wissen, wen oder was es zu erobern gilt. Das Objekt kann man in einer mehr oder weniger globalen Variablen zur Verfügung stellen.
Darum, die Elemente, die ihre Zustände gegenseitig bedingen sollen, einander auch irgendwie "bekannt" zu machen, kommst du m.E. nicht herum. Das ist aber auch im OO-Umfeld gang und gäbe. Du scheinst aber anzunehmen, ein Event-Modell wäre eine "Wunderwaffe", die einem das abnimmt?
In gewissem Sinne ja.
Wenn du sowas haben willst, musst du es m.E. selbst implementieren.
Bin gerade dabei, mit Hilfe von selbstdefinierten Events...
Warum soll das Anzeigemodul irgendetwas "abholen"?
Weil der Befehl zum Anzeigen manchmal auch gar nicht vom Rechnermodul kommt, sondern von einem anderen, welches wiederum nichts vom Rechnermodul weiß.
Damit widersprichst du dir selber - du sagst doch gerade, dass das Anzeigemodul die berechneten Ergebnisse mehrerer Rechner anzeigen können soll (nacheinander).
Nein, das hab' ich so nicht gesagt. Es geht ja nicht wirklich um einen Taschenrechner. So kommt es z.B. vor, dass u.a. eine Art Rechner bemüht wird, neben anderen Modulen, und wenn alles fertig ist, heißt es "Anzeigen!", und zwar alle Ergebnisse aus den einzelnen Modulen gleichzeitig. Die Routine, die schließlich die Anzeige initiiert, muss dazu – so ist es aktuell – die Schnittstellen aller Module kennen, die Daten daraus zusammenklauben und an die Methoden des Anzeigemoduls übergeben.
Jetzt will ich aber das Anzeigemodul selber – oder besser gesagt die einzelnen anzeigenden DOM-Elemente – mit dem nötigen Wissen über die Modul-Schnittstellen ausstatten, die es anzuzeigen gilt, und ihr Verhalten ( d.h. neu anzeigen oder nicht, aktivieren oder deaktivieren, verschwinden oder erscheinen usw. usf.) über Events steuern. Das erscheint mir sinnvoll, weil oft mehrere gleichzeitig betroffen sind, und ich nicht für jeden Fall eine Liste der Betroffenen zusammenstellen und durchlaufen will.
Mal sehen, vielleicht wird es auch ein Schuss in den Ofen. Dass evtl. zu viele von Events belästigt werden, die sie gar nichts angehen, könnte wirklich zum Performance-Problem werden, da hast du sicher recht.
Gruß, Don P