callback auf funktion außerhalb des scopes

[chwin]

Hallo

ich habe ein laufähiges Programm das über die letzten 2 Jahre immer weiter gewachen ist.
Leider hat sich dadurch vollkommen undurchsichtiger Code gebildet, den ich selber nicht mehr verstehe.
Daher habe ich mir vorgenommen das ganze neu aufzuziehen.

Wichtigster Grundsatz: es soll klar getrennt sein (Daten Empfang, Verarbeitung und Speicherung)

Im Grunde empfange ich daten per AMQP, verarbeite diese und Speichere die Informationen in einer Datenbank.

Als pseudocode sieht da so aus:

Code: Alles auswählen

class aussenwelt:
	get_data_fom_outside(callback=intern.verarbeitung)
	

class intern:
	def verarbeitung(daten):
		#tue etwas mit daten
		schreibe_in_datenbank(daten)


class datenbank:
	def schreibe_in_datenbank(daten):
		#tue etwas

extern = aussenwelt()
verarb = intern()
speicherung = datenbank()

Leider habe ich keinen Plan, wie ich mit der Callbackfunktion in der Klasse "Aussenwelt" die Verarbeitung in der Klasse "innen" erreichen soll.

Die Trennung ist so gewählt, weil ich für "Aussenwelt" verschiedene Versionen habe, je nach dem woher die Daten kommen.
Die Datenbank möchte ich auch austauschbar haben.

Google war bisher nicht mein Freund bzw hat mich nicht in die richtige Richtung geführt.
Ein Hinweis wonach ich googlen muss würde schon reichen.


Vielen Dank schonmal

Christian

[BlackJack]

@chwin: Du musst dem `Intern`-Exemplar das `Datenbank`-Exemplar bekannt machen, also beispielsweise beim Erstellen als Argument übergeben. Also rein technisch, ohne jetzt darauf einzugehen ob die Aufteilung oder die Namensgebung Sinn macht:

Code: Alles auswählen

class Intern(object):
    
    def __init__(self, datenbank):
        self.datenbank = datenbank

    def verarbeitung(self, daten):
        # Tue etwas mit `daten`.
        self.datenbank.schreibe(daten)
 
 
class Datenbank(object):

    def schreibe(self, daten):
        # Tue etwas.


def main():
    datenbank = Datenbank()
    verarbeiter = Intern(datenbank)

[Alfons Mittelmeyer]

Da gibt es eine einfache Lösung mit folgendem Code

Code: Alles auswählen

class EventBroker():
    def __init__(self):
        self._dictionary_ = {}
 
    def subscribe(self,message_id,callback):
        self._dictionary_[message_id] = callback
 
    def publish(self,message_id,*args,**kwargs):
        self._dictionary_[message_id](*args,**kwargs)
 
eventbroker = EventBroker()
publish = eventbroker.publish
subscribe = eventbroker.subscribe

Wenn Deine Module dieses Modul importieren, ist entfernter Funktionsaufruf möglich (auch Methoden oder Funktionen in Funktionen (Closures))

Bei subscribe wird eine ID und eine Funktionsreferenz angegeben. Danach kann diese Funktion von überallher über publish(ID,*args,**kwargs) aufgerufen werden. Dieses Verfahren hat sich prächtig bewährt in solchen Fällen, wie dem Deinen.

Das geht dann so:

Code: Alles auswählen

from eventbroker import subscribe,publish

class aussenwelt:

    publish('VERARBEITUNG',get_data_fom_outside())
   
 
class intern:
    
    def __init__(self):

        subscribe('VERARBEITUNG',self.verarbeitung)

    def verarbeitung(self,daten):
        #tue etwas mit daten

        publish('WRITEDATA',daten)
 
 
class datenbank:

    def __init__(self):

        subscribe('WRITEDATA',self.schreibe_in_datenbank)

    def schreibe_in_datenbank(self,daten):
        #tue etwas
 
extern = aussenwelt()
verarb = intern()
speicherung = datenbank()

[chwin]

Hallo

vielen Dank erstmal, ich werde mir das nochmal genauer ansehen.


Grüße
Christian

[__deets__]

Die Indirektion ueber den von Alfons gezeigten Mechanismus ist unnoetig, und im Zweifel fuehrt sie dich wieder in die Untiefen der Verstaendnislosigkeit.

Die direkte Nutzung von Abhaengigkeiten via Argument an den Konstruktor ist klarer und verlaesst sich auch nicht auf globalen Zustand einer einzigen EventBroker Instanz.

Denn im Grunde benutzt du dadurch genau die gleichen globalen Aufrufe wie vorher. Theoretisch koennte man durch getrenntes Setup der Verbindungen eine leichte Verbesserung erreichen. Aber dann bleibt immer noch das unnoetige Muster von "publish('ein-name', ...)".

Ich rate dir also dringend dazu, diesen Vorschlag zu ignorieren.

[Alfons Mittelmeyer]

Die Indirektion ueber den von Alfons gezeigten Mechanismus ist unnoetig, und im Zweifel fuehrt sie dich wieder in die Untiefen der Verstaendnislosigkeit.

Die direkte Nutzung von Abhaengigkeiten via Argument an den Konstruktor ist klarer und verlaesst sich auch nicht auf globalen Zustand einer einzigen EventBroker Instanz.

Ein globaler Zustand ist auch die Softwarearchitektur. Da befinden sich Klassen und Funktionen in verschiedenen Modulen. Und das ist ein Zustand und zwar auch ein globaler.

Wenn die Software signalorientiert arbeitet, ist sie von einem solchen Aufteilungszustand völlig unabhängig. Man kann dann übersichtlich zusammenfassen, was sinnvoll zusammengehört. Man kann dann natürlich auch Klassen und Funktionen bunt gemischt wahllos und ohne Sinn in diverse Module verteilen. Würde aber wohl niemand tun, oder?

Jedenfalls ist klarer, wenn man sich nur auf den Messagefluß konzentriert und dann Softwareaufbau keine Rolle spielt.
Also man konzentriert sich dann nur mehr darauf: Welche Messages gibt es und was sollen sie tun. Das ist doch eine ganz einfache Architektur, oder?

[BlackJack]

@Alfons Mittelmeyer: Nein das ist keine ganz einfache Architektur, denn es ist eine zusätzliche Indirektion und damit eine zusätzliche Schicht die man verstehen muss. Und je mehr man die Komponenten voneinander entkoppelt, um so schwieriger ist es nachzuvollziehen wie der Programmfluss dann tatsächlich aussieht. Wenn man diese Entkopplung nicht tatsächlich *braucht* ist es einfach nur überflüssige, zusätzliche Komplexität.

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Nein das ist keine ganz einfache Architektur, denn es ist eine zusätzliche Indirektion und damit eine zusätzliche Schicht die man verstehen muss. Und je mehr man die Komponenten voneinander entkoppelt, um so schwieriger ist es nachzuvollziehen wie der Programmfluss dann tatsächlich aussieht. Wenn man diese Entkopplung nicht tatsächlich *braucht* ist es einfach nur überflüssige, zusätzliche Komplexität.

7 Programmzeilen sind keine besondere Koplexität, die man schwer versteht. Und wozu muss man wissen, wer alles wen aufruft. Ein Steuergerät im Auto mißt die Geschwindigkeit und sendet sie bei Änderung. Da braucht man nicht verstehen, wer alles die Information braucht und was dann alles woanders aufgrund dessen aufgerufen wird. Info senden und fertig. Alledings ist dieser sehr simple Eventbroker nicht für mehrere Empfänger ausgelegt. Wenn jemand einen erweiterten Eventbroker benötigt, dann braucht er es nur zu sagen.

Außerdem, hätte man so etwas gleich benutzt, wäre es gar kein Thema, jetzt den Code sinnvoll auf Module aufzuteilen. Wenn man jetzt wieder solche Referenzen hat und untergliedert später weiter, hat man genauso wieder dasselbe Problem.

[BlackJack]

@Alfons Mittelmeyer: Wenn man ein Programm verstehen will muss man verstehen was von wo aufgerufen wird. Wenn man an irgend einer Schnittstelle Änderungen durchführt, muss man schauen wo die aufgerufen wird und dort dafür sorgen das die Aufrufe geändert werden, damit es wieder passt. Je mehr man das voneinander entkoppelt, um so schwieriger wird es diese Verbindungen nachzuvollziehen.

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Wenn man ein Programm verstehen will muss man verstehen was von wo aufgerufen wird. Wenn man an irgend einer Schnittstelle Änderungen durchführt, muss man schauen wo die aufgerufen wird und dort dafür sorgen das die Aufrufe geändert werden, damit es wieder passt. Je mehr man das voneinander entkoppelt, um so schwieriger wird es diese Verbindungen nachzuvollziehen.

Sorry, anscheint begreifst Du das Prinzip nicht. Nehmen wir an, Du bekommst einen Anruf aus Amerka. Mußt Du verstehen, über welche Vermittlungsstellen und Relaisstationen und Satelliten der verbunden ist? Ist doch völlig egal. Oder nimmst Du den Anruf nicht entgegen, weil Du das nicht weißt?

Außerdem ist der Eventbroker das Gegenteil vom Anruf über verschiedene Instanzen oder Parameterweiterreichung nach dem Prinzip von Baum zu Baum, von Ast zu Ast, von Ästchen zu Ästchen, von Zweig zu Zweig, von Zweiglein zu Zweiglein und schließlich zum Blatt.

Es ist gleich zum Blatt, wo immer das auch ist, und ohne Umwege, wenn man mal von dem über das Dictionary absieht. Es ist also der direkte Weg.
Da wird viel überflüssiger Code geschrieben, bei dem es nur um Parameterweiterreichung geht. Und genau das muß nicht sein.

[snafu]

Die Rede ist hier von technischen Aspekten aus der Sicht eines Programmierers, der Code verstehen soll. Da passt das Beispiel mit dem Anruf aus Amerika nicht wirklich. Es geht hier ja gerade nicht um den Endanwender, sondern um den Spezialisten. Und der würde sich sehr wohl dafür interessieren, worüber der Anruf aus Amerika verläuft...

Du willst immer alles so schön einfach machen, aber du merkst nicht, dass es in Wirlichkeit viel komplizierter und schwerer zu warten ist.

Und du übernimmst hier gefühlt 10-20% aller Threads, um den Leuten deine Ideen aufzuzwingen. Ideen, die außer dir niemand gut findet. Du bist einfach nur extrem nervig und ich wünschte, ich könnte dich blockieren, um deinen Stuss in keinster Form mehr wahrnehmen zu müssen. Leider aber geht das hier nicht.

[noisefloor]

Hallo,

"EventBroker" mögen ja manchmal für manchen Sachen sinnvoll sein. Aber hier ist es in der Tat so, dass es einfach nur mehr Code ist, aber das Ergebnis das selbe wie in BlackJacks Beispiel. Ergo: hier ist es sinnlos.

Dem Sprichwort nach ist Einsicht ja der erste Weg zu Besserung, aber Besserung ist hier wohl leider wieder nicht in Sicht...

BTW: wenn ich aus den USA angerufen werden (was wirklich in der Tat mehrmals die Woche vorkommt), interessiert mich der Weg der Verbindung sehr wohl. Schließlich will ich wissen, ob die NSA gerade mit hört oder nicht *SCNR*

Gruß, noisefloor

[Alfons Mittelmeyer]

Die Rede ist hier von technischen Aspekten aus der Sicht eines Programmierers, der Code verstehen soll. Da passt das Beispiel mit dem Anruf aus Amerika nicht wirklich. Es geht hier ja gerade nicht um den Endanwender, sondern um den Spezialisten. Und der würde sich sehr wohl dafür interessieren, worüber der Anruf aus Amerika verläuft...

Welchen Spezialsten meinst Du, einen solchen, der eine Telefonapp auf dem Smartphone programmiert? Den intgeressiert das auch nicht.

Du willst immer alles so schön einfach machen, aber du merkst nicht, dass es in Wirlichkeit viel komplizierter und schwerer zu warten ist.

Wie kommst Du auf diese Idee? Es ist einfacher und einfacher zu warten.

Und du übernimmst hier gefühlt 10-20% aller Threads, um den Leuten deine Ideen aufzuzwingen. Ideen, die außer dir niemand gut findet.

Ja, wie kann ich jemand was aufzwingen, indem ich meine Meinung kund tue? Darf man seine Meinung nicht mehr äußern? Schließlich soll man ja Meinungen äußern und diskutieren dürfen.

Du bist einfach nur extrem nervig und ich wünschte, ich könnte dich blockieren, um deinen Stuss in keinster Form mehr wahrnehmen zu müssen. Leider aber geht das hier nicht.

Wenn Du die Meinung hast, dass das, was ich schreibe Stuss sei, dann darfst Du die natürlich äußern. Schön wäre aber auch eine Begründung, warum Du das meinst. Außerdem sind Message basierte Systeme keinerlei Stuß, sondern werden überall in moderner Software eingesetzt. Ohne diese könntest Du nicht einmal etwas in einem Forum schreiben. Du drückst auf einen Button im Browser um das Geschriebene abzusenden. Dann wird eine http Message losgesandt, von der Du nicht weißt, auf welchem Weg sie geroutet wirde. Du weißt auch nicht, auf welchem Webserver das landet. Sie landet dort in einer Queue und wiederum weißt Du nicht, welche Programmiersprache dahintersteckt und welche Methode sie von der Queue abholt und welche Methode dann letztendlich aufgerufen wird, um das dann letztendlich im Forum zu speichern und als Webseite verfügbar zu machen. Um etwas tun zu können oder ein Programm zu schreiben, braucht man eben Vieles nicht zu wissen. Man muß aber wissen, wie etwas zu tun ist, damit es auch funktioniert. Man muß eben über die Schnittstellen Bescheid wissen. Die Internas dagegen gehen normalerweise niemand etwas an und sollten nach außen hin auch am Besten unsichtbar sein, damit man Da nicht von außen zum Reinwursteln anfängt.

[Sirius3]

@Alfons Mittelmeyer: ein PubSubSystem ist immer deutlich komplexer und nur wenn es wirklich nötig ist und die Vorteile überwiegen, sollte man es einsetzen. Und dann richtig und nicht so ein zusammengestückelter ungetesteter Code. Wenn man das versucht einem Anfänger anzudrehen, ist das höchst fahrlässig. Diskussionen sind gut, aber nicht in Threads, wo jemand ein konkretes Problem hat.

[BlackJack]

@Alfons Mittelmeyer: Ich begreife das Prinzip sehr wohl und setze das Publisher/Subscriber-Entwurfsmuster auch ein. Allerdings da wo es wirklich sinnvoll ist, und nicht einfach überall. Du kommst mit diesem `EventBroker` ja andauernd um die Ecke.

Der „Anruf aus Amerika“-Vergleich hinkt ganz gewaltig. Mit Spezialist ist der Telefontechniker gemeint, der das System verändern, warten, und Fehler suchen muss. Den interessiert es tatsächlich worüber die Anrufe unter welchen Umständen und mit welchen Parametern laufen.

Eine *zusätzliche Indirektion* kann per Definition schon nicht einfacher sein.  Es ist eine zusätzliche Schicht. Auf die man in diesem Fall sehr gut verzichten kann. So ziemlich jedes Programm verzichtet darauf, denn so gut wie kein Programm nutzt für die Kommunikation zwischen allen Objekten so eine Zwischenschicht. Nachrichten zwischen Objekten verschicken ist schon der normale Methodenaufruf. Das geht auch ohne zusätzlichen Vermittler der ausser Komplexität nichts bietet und in Deinem Fall das ganze sogar nicht unflexibler macht, weil das schon wieder globaler Zustand ist.

Du zwingst Deine Ideen auf, in dem Du sie nicht nur einmal zum Diskutieren in *einem* Thema vorstellst, sondern den gleichen Kram immer und immer wieder in Themen rein drückst, obwohl Du eigentlich gemerkt haben solltest wie das ankommt und welche, immer gleichen Diskussionen sich darauf hin im Kreis drehen. Und das bei Fragen von nichtsahnenden Neulingen, die mit Deinem Code und der Diskussion in der Regel nichts anfangen können.

Warum das Stuss ist wurde bereits an anderer Stelle zur Genüge durchgekaut. Es wird nicht besser oder anders wenn Du da in jedem Theme wieder aufs neue drüber diskutieren möchtest. Es nervt. Nur wenn keiner was sagt, dann ”gewinnst” Du in dem Du das immer und immer wieder wiederholst. Ich denke da muss man langsam mal mit Moderationsmitteln dran arbeiten…

[Alfons Mittelmeyer]

@Alfons Mittelmeyer: Ich begreife das Prinzip sehr wohl und setze das Publisher/Subscriber-Entwurfsmuster auch ein. Allerdings da wo es wirklich sinnvoll ist, und nicht einfach überall. Du kommst mit diesem `EventBroker` ja andauernd um die Ecke.

Eine *zusätzliche Indirektion* kann per Definition schon nicht einfacher sein. Es ist eine zusätzliche Schicht. Auf die man in diesem Fall sehr gut verzichten kann. So ziemlich jedes Programm verzichtet darauf, denn so gut wie kein Programm nutzt für die Kommunikation zwischen allen Objekten so eine Zwischenschicht. Nachrichten zwischen Objekten verschicken ist schon der normale Methodenaufruf. Das geht auch ohne zusätzlichen Vermittler der ausser Komplexität nichts bietet und in Deinem Fall das ganze sogar nicht unflexibler macht, weil das schon wieder globaler Zustand ist.

Also, ich komme nicht dauernd damit um die Ecke, Ich habe das vorgeschlagen, wo es eine Lösung sein könnte. Ich weiß ja nicht, ob so eine Verbindung, wie Du sie vorgeschlagen hast, genügt. Reicht es, dass damit die obersten Klassen in der Hierarchie verbunden sind oder gibt es auch Klassen darunter, die auch mit etwas im anderen Modul kommunizieren müssen? In diesem Fall wäre ein Hangeln durch die Klassenhierarchie mit vielen Parameterweitergaben eine Verkomplifizierung und eine immense Indirektion. Da wäre der Eventbroker keine *zusätzliche Indirektion* sondern geradezu eine entflechtende *Direktion*. Ich kann natürlich den vorliegenden Fall nicht beurteilen, weil ich die Einzelheiten nicht kenne. Aber sicher ist es nicht verkehrt dass der Anwender auch diese Möglichkeit kennt

Der „Anruf aus Amerika“-Vergleich hinkt ganz gewaltig. Mit Spezialist ist der Telefontechniker gemeint, der das System verändern, warten, und Fehler suchen muss. Den interessiert es tatsächlich worüber die Anrufe unter welchen Umständen und mit welchen Parametern laufen.

Wenn ein Fehler in Buxtehude im Telefonnetz auftaucht, braucht man sicherlich nicht unbedingt zu wissen, wie das Telefonnetz in Aserbeidschan funktioniert, weil bei einem Anruf auch von dort der Fehler passiert ist.

Du zwingst Deine Ideen auf, in dem Du sie nicht nur einmal zum Diskutieren in *einem* Thema vorstellst, sondern den gleichen Kram immer und immer wieder in Themen rein drückst, obwohl Du eigentlich gemerkt haben solltest wie das ankommt und welche, immer gleichen Diskussionen sich darauf hin im Kreis drehen. Und das bei Fragen von nichtsahnenden Neulingen, die mit Deinem Code und der Diskussion in der Regel nichts anfangen können.

Ich zwinge überhaupt niemand etwas auf. Ich stelle nur kurz eine Idee vor. Und Du und andere zwingen dann mir endlose Diskussionen deswegen auf.

Warum das Stuss ist wurde bereits an anderer Stelle zur Genüge durchgekaut. Es wird nicht besser oder anders wenn Du da in jedem Theme wieder aufs neue drüber diskutieren möchtest. Es nervt. Nur wenn keiner was sagt, dann ”gewinnst” Du in dem Du das immer und immer wieder wiederholst.

Sorry, ich will da gar nichts zur Genüge durchkauen und ich möchte auch gar nichts immer wieder aufs Neue darüber diskutieren. Ich hatte nur gedacht dem Anwender könnte es vielleicht nützen, was ich aber nicht beurteilen kann. Und mich nervt es gewaltig, wenn man mir dann immer wieder endlose Diskussionen aufzwingt.

Ich denke da muss man langsam mal mit Moderationsmitteln dran arbeiten…

Es wäre nicht schlecht, wenn es in diesem Forum auch endlich so etwas wie einen Moderator gäbe. Damit meine ich jemanden, der auch weiß, was ein Moderator ist. Moderare heißt ja mäßigen. Das wäre jemand, der lenkend eingreift, wenn eine Diskussion zu hitzig wird, damit sie nicht aus den Fugen gerät und alles in gezügelten Bahnen läuft.

Aber hier im Forum scheinen ja gewisse Personen ihr Unwesen zu treiben, indem sie User vergraulen, sie zur Schnecke machen und beleidigen. Eine kleine Notiz wäre etwa das:

viewtopic.php?f=18&t=38748&start=60#p313454

Aber es sind auch andere, die sich gar nicht mehr rühren und mit diesem Forum nichts mehr zu tun haben wollen. Manche Subforen sind schon regelrecht tot. Wenn es so etwas wie Moderatoren hier gäbe, könnte das ein sehr lebendiges Forum sein, in dem viele ihre Meinungen austauschen könnten oder Ideen, die andere beflügeln.

So aber rührt sich leider sehr wenig.

[DeaD_EyE]

Jemand, der jetzt nicht unbedingt aus der Softwareentwicklung kommt, stellt eine einfache Frage.
Die Frage wurde einfach beantwortet.

Dann kommst du mit einer Antwort, die den Rahmen sprengt und die Struktur weiter verkompliziert.
Würdest du dafür deine Hand ins Feuer legen, dass der TO nach einem Jahr noch weiß, was er da gemacht hat ohne den Code komplett zu lesen?

[snafu]

Ich kann natürlich den vorliegenden Fall nicht beurteilen, weil ich die Einzelheiten nicht kenne. (...) Ich hatte nur gedacht dem Anwender könnte es vielleicht nützen, was ich aber nicht beurteilen kann.

Genau das ist der Punkt: Deine gutgemeinten Ratschläge sind oftmals unangebracht in der jeweiligen Situation. Oder zumindest ist in dem Moment, wo du dein Schema F bringst, überhaupt noch nicht klar ob ein "Komplexitätsmonster" hilfreich ist. Du knallst es einfach bei jeder Gelegenheit raus ohne den Anwendungsfall ernsthaft beurteilt zu haben. Du würdest wahrscheinlich immer einen Bagger nehmen, egal ob du ein Haus baust oder eine Blume pflanzt.

EDIT:
Und wenn du grundsätzlich irgendwelche Fälle abdecken willst, die in ferner Zukunft in einem Paralleluniversum eventuell mal auftreten könnten, dann ist die durch Python gelebte Philosophie nicht so wirklich auf dich zugeschnitten...

[Alfons Mittelmeyer]

@chwin: Du musst dem `Intern`-Exemplar das `Datenbank`-Exemplar bekannt machen, also beispielsweise beim Erstellen als Argument übergeben. Also rein technisch, ohne jetzt darauf einzugehen ob die Aufteilung oder die Namensgebung Sinn macht:

Ja tolle Idee! Und zuerst muss dann wohl das eine Modul bekannt geben, dass das andere dazu eine Klasse Intern aufrufen soll und worüber, gibt sie das wieder bekannt.

Außerdem ist das nur noch eine Zunahme der wohl eh schon bestehenden vielen Verflechtungen.

Zu klären wäre der Ablauf und ob sich daraus eine Aufrufreihenfolge ergibt

Am Besten beginnt man mit vier Modulen:

Datenempfang
Datenverarbeitung und Logik, evtl. Anbindung an GUI
Datenspeicherung
Gemeinsame Systemroutinen

Wenn das System nur auf den Empfang von Daten reagiert, würde der Datenempfang in der Aufrufreihenfolge oben stehen. Zu klären wäre aber noch, ob da nicht noch eine Bedieneroberfläche mit hinein muss und ob das eine GUI ist.

Gemeinsame Systemroutinen wären Grundfunktionen des Systems, die eventuell von allen anderen Modulen genutzt werden. Und dieses Modul ruft keinesfalls etwas von anderen Modulen auf. Eventuell wird das auch gar nicht benötigt. Zur Zeit ist alles in diesem Modul und es gilt, dieses Modul zu leeren und auf die anderen Module aufzuteilen.

Außer Aufrufen dieser Systemroutinen Routinen soll der Datenempfang nur die Datenverarbeitung aufrufen und die Datenverarbeitung nur die Datenspeicherung.

Zu klären wäre aber, ob der Datenempfang rein von außen kommt, oder auch von der Logik abhängt, sodass die Logik Einstellungen für den Datenempfang setzt. Sollte das so sein, dann bräuchte man auf alleroberter oberster Ebene noch ein Modul, mit dem solche Einstellungen vorgenommen werden können.

Dann wohl so:

[codebox=text file=Unbenannt.txt]Einstellungen mit Einstellogik und Anbindung an GUI
| | |
Datenempfang | |
| | |
Datenverarbeitung |
| |
Datenspeicherung
| | | |
Eventuelle System Grundfunktionen (aufrufbar für alle)[/code]

Wenn man dabei aber keine hart kodierten Aufrufe in anderen Modulen vornehmen will, oder sich auch nicht sicher ist, ob man funktionale Einheiten später nicht weiter in einzelne Module unterteilen möchte, geht auch das nur mit Messages. Ansonsten bekommt man immer einen unnötigen Aufwand für Erweiterungen, Umstrukturierungen, Wartung und Pflege

[Sirius3]

@Alfons Mittelmeyer: schön, dass Du die Basics kennst, Eingabe-Verarbeitung-Ausgabe, dafür gibts auch schon einen Wikipediaartikel. Und dann machst Du diese schöne Herleitung wieder durch Dein Message-System kaputt. Umstruktrierungen, Erweiterungen, Wartung und Pflege gehören zu jedem Projekt dazu. Jetzt mußt Du nur noch erkennen, dass Deine Messages nichts an den ganzen Punkten verbessern, sondern nur zusätzliche Komplexität dazupackt, so dass Wartung und Pflege unnötig umständlich macht.