__deets__ hat geschrieben:Und wenn man jedem Event seinen eigenen Broker gibt, dann heisst das "Observable Pattern" und findet sich zB in der Gestalt von Signal/Slots in Qt. Und dann wird deine "Vorwahl" einfach nur das Objekt selbst, und du bist endlich da angekommen, wo der Rest sein Mitte der 90er schon war.
Nö, vielleicht ist da endlich der Rest da angekommen, dass ich nichts Außergewöhnliches und Unerhörtes gebracht hatte, sondern nur etwas völlig Normales, das seit Mitte der 90er in sehr vielen Bereichen eingesetzt wird.
__deets__ hat geschrieben:Und da wird auch nicht "gematscht" wie du so schoen herablassend sagst (aber spaeter wieder Beschweren ueber die Formulierungen anderer), sondern ein sauberes loose-coupling erreicht, bei dem Objekte einer Schicht die einer anderen ueber diverse Zustandsaenderungen informieren. Das *muss* aber nicht besser sein als das man periodisch (oder aufgrund anderer Ereignisse) einfach *abfragt*, was denn so Phase ist.
Natürlich wird da nichts gematscht, sondern man hält sich an die bereits vorhandenen sauberen Schnittstellen. Kein Mensch käme auf die Idee in den Source Code von Qt seine Callbacks für eine Anwendung hineinzumantschen. Das wäre nämlich gematscht und für so ähnliches woanders bin ich auch nicht dafür.
[quote="__deets__"Denn das Observable-Pattern hat so seine Tuecken, wenn man implizit Code schreibt, der sich auf eine eigentlich nirgends klar definierte Ereignisreihenfolge verlaesst. Ist also nicht so ganz simpel.[/quote]Man muß eben gewohnt sein, ereignisorientiert zu programmieren und darf nicht erwarten, dass nach Senden von etwas dann gleich unmittelbar auch schon das Ergebnis da ist. Im Normalfall laufen Events auch über eine Queue
__deets__ hat geschrieben:Ja, Events sind ein hilfreiches Ding. Manchmal. Mit globalem Broker (wie du sie hier immer propagierst, anderslautendes ist immer nur Gerede, noch nie gesehen) aber nur fuer sehr, sehr eingeschraenkte Zwecke. Und darum bei weitem nicht das von dir propagierte Allheilmittel.
Ob etwas global ist kommt darauf an, ob man nur einen Knoten hat, also nur Ortsnetz oder viele. Für kleine Anwendungen von ein paar Modulen reicht wohl ein Eventbroker vollständig aus. Und mit Messages wird überall gearbeitet, die ganzen Systeme im Automotiv Bereich im Militärischen Bereich in luft und Raumfahrt arbeiten damit, da gibt es verschioedene Busse, wie etwa CAN, MOST, Flexray über die dann Signale übertragen werden. Die haben dann auch einen Physikalischen Layer und Protokollstacks und arbeiten mit Qeues. Ich hatte hier nur einen ganz simplen mit indirektem Funktionsaufruf gezeigt, denn eine Qeue und weitere Features erleichtern nicht das Verständnis. Hast ja gelesen, dass jemand die Zwei Zeilen Code, nämlich Funktionsdefinition mit Parametern und dann Aufruf über Dictionary bereits als Komplexitätsmonster bezeichnet hat.
Und ein Allheilmittel ist so etwas keineswegs. Man kann dann zwar den Code leicht in andere Module verteilen. Ob er dabei aber übersichtlicher wird ist fraglich.
Da sollte man vielleicht doch anders vorgehen. Zuerst einmal in der Source verschiedene Bereiche machen und dort hineinmoven, was zu diesem Bereich gehört. Und wenn man dann damit letztendlich zufrieden ist, kann man die Auslagerung vorbereiten.
Und eine solche Vorbereitung sähe dann im Mainscript so aus:
Code: Alles auswählen
# import empfang
# import speichern
import verarbeitung
verarbeitung.init(verarbeitung = verarbeitung,
empfang = verarbeitung,
speichern = verarbeitung)
Und wenn man diese Werte dann in globalen Variablen speichert, kann man schon einmal die Aufrufe richtig benennen. Und wenn sie richtig benannt sind, kann man dann aufteilen.
Ob der Code dann schon schön ist, ist immer noch fraglich. Aber es schadet nichts über Messages nachzudenken. Nicht unbedingt, dass man das implementieren soll. Aber es wäre gut über sinnvolle Schnittstellen und sinnvolle Benennungen nachzudenken. Und kann solche sinnvollen Schnittstellen dann ja auch als Mehodeninterfaces implementieren.
