Kommunikation zwischen Objekten
-
Hallo Leute,
wollte euch mal etwas halbwegs generelles Fragen:
Wie kann ich am besten eine Kommunikation zwischen zwei verschiedenen Objekten erstellen? Die beeinflussen sich gegenseitig und brauchen auch die Informationen des anderen. Es handelt sich um ein Frontend und ein Backend ( welches aus vielen einzelnen Objekten gleicher Klasse besteht ).
Der einzige Ansatz der mir in den Kopf gekommen ist, ist eine neue Klasse zu erstellen die ich vollkommen Statisch halte und dort die Objekt Pointer speicher und sowas global drauf zugreifen kann.
Das ist nun leider keine schöne Lösung, aber immerhin eine.
Hat jemand anderes sonst noch eine Idee wie ich es machen könne?
Gruß Akoww
//Nachtrag
Das Frontend und Backend laufen auf zwei verschiedenen Thread, das könnte es ja auch zu Problemen kommen wenn bei Threads gleichzeitig einen Wert bearbeiten.
-
akoww schrieb:
Wie kann ich am besten eine Kommunikation zwischen zwei verschiedenen Objekten erstellen?
Wenn du meinst, die sollen einfach aufeinander zugreifen können: Einfach Zeiger/Referenzen auf das jeweils andere Objekt speichern.
-
Also :
Das Frontend läuft auf einem Thread und soll auf die Methoden des Backend greifen können. Das Problem wäre dann halt, dass Teile das Backend über den Thread vom Frontend laufen, und wenn genau dann in dem Moment beide Threads auf eine Datei zugreifen, kann es zu Problemen kommen.
Das Backend hat es da etwas einfacher, es soll einfach nur Daten irgendwo ablegen (keine Funktionen aufrufen) die sich das Frontend schnappen soll.
-----
Jetzt ist mir noch eine Idee gekommen, und zwar baue ich nen Buffer in den das Frontend die zu erledigende Aufgabe reinschreibt, und dann Backend ließt es aus und arbeitet diese dann ab. Das Problem wäre halt dann wieder, dass man die Aufgaben irgendwie abspeichern muss und dann wieder auslesen/parsen muss. Das ist recht viel Arbeit.
-
Hört sich so an, als hättest du wenig Ahnung, wovon du redest und würdest dir da was abenteuerliches zusammenfriemeln.
-
ich habe erlich gesagt keine Ahnung von Threading. Deshalb frage ich ja hier.
-
Nicht nur von Threading, auch von Softwarearchitektur und Schichtenarchitektur und wahrscheinlich auch von Entwrufsmustern. Die Frage kann man nicht so einfach beantworten, bzw. eine konkrete Antwort würde wenig bringen. Du musst da einfach noch einiges lernen.
Wenn du es sofort lösen willst, nimm die Lösung, die du selber vorgeschlagen hast (du hast zumindest richtig erkannt, dass sie nicht schön ist). Alles andere wirst du mit der Zeit lernen, wenn du dabei bleibst. Aber das geht alles nicht von heut auf morgen.
-
Dieses generelle "Du kannst das nicht, lern es" ist zwar nicht komplett von der Hand zu weisen, aber wirkt auf mich doch ziemlich nutzlos und destruktiv. Er will doch was lernen, aber braucht Hinweise, wo und wie er es lernen kann. Was hilft es da zu schreiben, dass er es nicht kann, was er doch schon weiß und... Egal. Ist natürlich einfach zu schreiben... Ich versuche Mal ein wenig Ideen und ein paar Schlagwörter zu bringen, vielleicht hilft das.
akoww schrieb:
Das Frontend läuft auf einem Thread und soll auf die Methoden des Backend greifen können.
Soweit alles in Ordnung.
Das Problem wäre dann halt, dass Teile das Backend über den Thread vom Frontend laufen,
Warum? Das sollte so nicht sein. Man kann das über Signal/Slots-Mechanismen oder Observer-Pattern lösen. Auf die Weise werden Nachrichten abgelegt und zu einem Zeitpunkt, der dem jeweiligen Thread passt, ausgeführt. Dass die Dinge in der korrekten Reihenfolge im Bezug auf die beiden Threads ausgeführt werden, nennt man Synchronisation (alles Schlagworte zum googlen).
und wenn genau dann in dem Moment beide Threads auf eine Datei zugreifen, kann es zu Problemen kommen.
Ich bin nicht sicher, ob Front- und Backend auf die Datei zugreifen sollten, reicht da nicht einer? Das sollte schon zentral gestehen. Gemeinsam genutzte Ressourcen (wobei mindestens einer schreibt, lesend ist ja egal) sollte man bzgl. des Zugriffs sperren, dafür gibt es Mutexe.
Das Backend hat es da etwas einfacher, es soll einfach nur Daten irgendwo ablegen (keine Funktionen aufrufen) die sich das Frontend schnappen soll.
Das verwirrt mich, eben klang es durchaus so, dass das Backend z.B. auf das Dateisystem zugreift und auch noch andere Dinge zu erledigen hat.
Jetzt ist mir noch eine Idee gekommen, und zwar baue ich nen Buffer in den das Frontend die zu erledigende Aufgabe reinschreibt, und dann Backend ließt es aus und arbeitet diese dann ab. Das Problem wäre halt dann wieder, dass man die Aufgaben irgendwie abspeichern muss und dann wieder auslesen/parsen muss. Das ist recht viel Arbeit.
Siehe oben bzgl. Signal/Slots oder Observer bzw. Eventhandling, ganz egal, wie man das nennt. Je nach Framework setzt man das anders um, hier wäre es also schon hilfreich zu wissen, mit welchen Frameworks Du arbeitest. Die Idee des Abarbeitens mit einer Queue ist schon ziemlich gut, genau das wird umgesetzt.
Lass Dich nicht unterkriegen, Du kriegst das schon hin, informieren musst Du Dich natürlich trotzdem.
-
Eisflamme schrieb:
Ist natürlich einfach zu schreiben...
Richtig, ist ein wichtiger Grund. Vor allem wenn man bedenkt, dass jeden Tag fünf von solchen Kandidaten kommen, denen man allen dasselbe erklären müsste, wobei die Erklärungen beliebig lang werden können.Was du schreibst ist generell richtig, aber ich möchte nicht, dass der TE den Eindruck bekommt, man könne sich einfach ein paar Schlüsselwörter ergoogeln und genauso weitermachen. Bzw. weitermachen kann man schon und sollte es auch, an Projekten lernt man am besten. Nur muss man im Hinterkopf behalten, dass da noch einiges dahintersteckt und sich bei Gelegenheit auch in die Materie einarbeiten.
-
Ja, kommen wirklich ständig solche Beiträge. Man müsste noch mehr mit FaQ erschlagen können, aber ist nicht so leicht.
Was meinst Du mit "in Materie einarbeiten" genau? Wenn er Observer versteht (und darüber hinaus z.B. noch andere Pattern liest, MVC durchliest und dann irgendwann versteht, dass viele Pattern in ihrer Bezeichnung v.a. auf Java abgestimmt sind und es in C++ teilweise "coolere" Möglichkeiten gibt), hat er ja schon einiges verstanden. Wenn es beim Begriff Softwarearchitektur nur um modulare Architektur mit klarer Trennung von Verantwortlichkeiten geht, hat er da auch schon was gelernt.
Und ein Buch dazu, wie man größere Architekturen mit C++ und den neuen Sprachmitteln aufbaut, habe ich noch nicht gefunden, ist wohl auch schwierig zu schreiben.
Aber sonst so, die ultimative Quelle bis auf vereinzelte Infos, die man sich dann im Hirn und mit Projekten selbst zusammenreimt... gibt es da was zu empfehlen? Ich würde einfach sagen, er muss halt noch mehr lesen.
-
Eisflamme schrieb:
Was meinst Du mit "in Materie einarbeiten" genau?
Mist, ich hatte gehofft, die schwammige Formulierung würde reichen
Ich finde, zum einen ist der Stoffumfang, der zu Softwarearchitektur dazugehört, ist recht groß. Da steckt schon einiges an Konzepten dahinter, die man verstehen muss. Wenn dann auch Hintergrundwissen fehlt, wird es noch mehr.
Ich glaub auch, und das find ich sogar wichtiger, dass das Verstädnnis für Softwarearchitektur erst langsam reifen muss, zumindest war das bei mir so. Es reicht nicht, die Entwurfs- oder Architekturmuster zu kennen. "Normale Menschen" denken nicht so, sondern gehen Probleme direkter an. Erst mit der Zeit entwickelt man ein Gefühl für die Software und mögliche Anforderungen/Probleme und fängt an, die Software entsprechend absrakt zu modellieren. Bei mir war (ist) es ein mehrstufiger Prozess, bei dem das Design der Software mit der Zeit immer mehr Abstraktionsebenen bekommt. Als als Schüler mit dem Programmieren angefangen habe, habe ich die Probleme, die ich mir gestellt habe, sehr direkt gelöst. Ich hatte aber schon immer eher größere Projekte im Sinn, an denen ich teilweise jahrelang gebastelt habe, daher war die direkte Lösung nur selten ausreichend. Ich habe dann meist festgestellt, dass ich bei jeder neuen Anforderung plötzlich lauter Probleme hatte. Codeduplizierung, schlechte Kapselung (bzw. anfangs gar keine Kapselung), zu viele Abhängigkeiten, Code nicht wiederverwendbar, immer mehr Sonderfälle, die ich behandeln musste... Irgendwann fängt man dann an, die Probleme nicht ganz so direkt zu sehen, sondern zu abstrahieren, und dann kann man schon wesentlich mehr Sonderfälle und Abhängigkeiten vermeiden, weil die Architektur das schon auf eine wesentlich elegantere Art und Weise berücksichtigt. Aber irgendwann kommt es wieder zu Problemen, wenn die Software noch komplexer wird. Dann fängt man an, noch abstrakter zu denken.
Ich denke, diesen Prozess muss jeder selber durchmachen. Paralell dazu gibts natürlich einige lesenswerte Bücher über die Softwarearchitektur. Ich denke, um das alles richtig zu verdauen, kann man durchaus 1-2 Jahre veranschlagen, wenn nicht mehr.