Sent and Receive Funktionen zwischen Objekten ermöglichen?

[berndoa]

Hallo,
kann man irgendwie ähnlich dem brief und Paketverkehr etwas aufsetzen sodass Objekte Sachen (wieder Objekte, ggbfls. mit einem String dabei) hin und herschicken können?

Weil "Standard" sage ich mal ist ja Folgendes:
Gegeben 2 Objekte a und b, die sich kennen.
a benutzt eine Methode die etwas "produziert" als Ergebnis.
Dies übergibt sie b, der in seiner Methode dadraus wieder was produziert.
Dieses Produkt wird an a gesendet, wo es wiederum von dessen methode vererwertet wird.
usw.


In java würde man da pblicherweise ja eine MethodenKaskade bauen, die mit jedem Schritt jhässlicher und länger wird:
a.methode1(b.methode2(a.methode4(b.methode2(.......))))

Also ich finde diese verschachtelten Methoden wo wie in der Rekursion die zuerst benutzten methoden gar nicht fertig werden solange nicht Alles innendrin fertig ist, einfach hässlich.
Mir wäre es da lieber, wenn man es so wie beim Briefverkehr irgendwie machen könnte:
a und b haben custom definierte "receive" und "sent" Funktionen.
Wird bspw. ein Paket von A nahc B geshcickt (in etwa "a.sent(paketobjekt)"),
dann würde B, wie bei so einem eventlistener, automatisch mittels receive das paket erhalten und je nach inhalt eben verschiedenes damit machen.
und dann natürlich, wenn gewünscht, auch wieder mittelss der eigenen sent funktion ein ggbfls. anderes Paket zurückschicken.

Unterschied zu oben:
Für a ist der job in dem Moment rum, wo die eigene sent methode abgearbeitet wurde.
wie b das paket kriegt, kann a egals ein, kriegt a nicht mit und muss auch nicht abwarten bis b seinen kram erledigt hat bevor es die eigene sent methode beenden kann.

Also keine immer länger und tiefer werdenden methodenkaskaden und aaufruftiefen wie oben.

So ähnlich würde ich mir das zumindest vorstellen bzw. erhoffen.

Lässt sich sowas in irgendeiner Form hinkriegen in java?

Im Prinzip so wie es auch zwischen server und client abläuft, jeder von beiden kann sachen erhalten und entsprechend reagieren. und auch nahc gutdünken mittels httprequests sachen rausschicken wohin und an wen es beliebt.

eben wie beim briefversand auch, wo für mich die arbeit zuende ist, sobald der brief wegeschickt ist (also im briefkasten eingeworfen wurde).
ragieren muss man erst wenn wieder ein brief eintrifft.

 

[Jw456]

Tipp: schaue mal nach Callback Methoden und Interfaces.

Eventhandler...

 

[httpdigest]

Das riecht schon wieder alles nach Overengineering bei dir.
Was du aktuell in deiner Beschreibung nicht schreibst, ist: Warum willst du das denn machen? Was genau ist der Anwendungsfall? Wofür genau willst du das so machen? Welches konkrete Problem willst du damit lösen?

 

[yfons123]

observerpattern mit Observer und Subscriber , functional interfacees ( haben wenig mit den interfaces zu tun die du kennst )

 

[mihe7]

In java würde man da pblicherweise ja eine MethodenKaskade bauen, die mit jedem Schritt jhässlicher und länger wird:

Sagen wir mal, wir haben eine Fabrik, die Autos produziert. Dafür brauchen wir einen Motor, für dessen Erstellung seinerseits Schrauben benötigt werden. Natürlich kann man das hässlich formulieren

Auto auto = autoFabrik.produziereAuto(motorenFabrik.produziereMotor(schraubenFabrik.produziereSchraubensatz()));

Macht hoffentlich kein Mensch. Stattdessen:

Schrauben schraubensatz = schraubenFabrik.produziereSchraubensatz();
Motor motor = motorenFabrik.produziereMotor(schraubensatz);
Auto auto = autoFabrik.produziereAuto(motor);

Unterschied zu oben:
Für a ist der job in dem Moment rum, wo die eigene sent methode abgearbeitet wurde.
wie b das paket kriegt, kann a egals ein, kriegt a nicht mit und muss auch nicht abwarten bis b seinen kram erledigt hat bevor es die eigene sent methode beenden kann.

Das wäre im Extremfall publish/subscribe-Messaging. Allerdings ist im Leben nichts umsonst: der Spaß kommt mit erheblicher Komplexität einher. Du siehst nur noch, dass irgendwo eine Nachricht versandt wird, weißt aber nicht unbedingt, wo die Nachricht Verwendung findet. Sprich: Du brauchst eine Möglichkeit, die Nachrichten nachvollziehen zu können, sonst läuft das wie bei der Post: keine Ahnung, wo Ihre Sendung ist...

 

[KonradN]

Nach der Beschreibung wäre es noch nicht einmal das Observerpattern, denn da wäre ja der Punkt:

Für a ist der job in dem Moment rum, wo die eigene sent methode abgearbeitet wurde.

nicht erfüllt.

Was hier beschrieben wurde, wäre einfach etwas wie ein Eventhandler wie er z.B. von UIs eingesetzt wird.

Also alles, was man braucht, ist ein Loop, das Events abarbeitet. Events wären hier einfach Dinge, die Ausgeführt werden sollen.

Das was ausgeführt werden kann, könnte man als Callable bezeichnen. Das, was diese Dinge ausführt, könnte man den Namen ExecutorService geben.

Und da könnte man ja mal in den java.util.concurrent Namespace schauen und mal sehen, was man so alles an Klassen findet. Evtl. finden sich ja auch Klassen mit den Namen, die ich genannt habe

Aber ganz wichtig ist die Aussage von @httpdigest, die ich nur unterstreichen kann:

Das riecht schon wieder alles nach Overengineering bei dir.
Was du aktuell in deiner Beschreibung nicht schreibst, ist: Warum willst du das denn machen? Was genau ist der Anwendungsfall? Wofür genau willst du das so machen? Welches konkrete Problem willst du damit lösen?

 

[berndoa]

Sagen wir mal, wir haben eine Fabrik, die Autos produziert. Dafür brauchen wir einen Motor, für dessen Erstellung seinerseits Schrauben benötigt werden. Natürlich kann man das hässlich formulieren

Auto auto = autoFabrik.produziereAuto(motorenFabrik.produziereMotor(schraubenFabrik.produziereSchraubensatz()));

Macht hoffentlich kein Mensch. Stattdessen:

Schrauben schraubensatz = schraubenFabrik.produziereSchraubensatz();
Motor motor = motorenFabrik.produziereMotor(schraubensatz);
Auto auto = autoFabrik.produziereAuto(motor);

Das wäre im Extremfall publish/subscribe-Messaging. Allerdings ist im Leben nichts umsonst: der Spaß kommt mit erheblicher Komplexität einher. Du siehst nur noch, dass irgendwo eine Nachricht versandt wird, weißt aber nicht unbedingt, wo die Nachricht Verwendung findet. Sprich: Du brauchst eine Möglichkeit, die Nachrichten nachvollziehen zu können, sonst läuft das wie bei der Post: keine Ahnung, wo Ihre Sendung ist...

Naja, müsste man halt zu jeder Nahcricht dazu schreiben, an wen sie gerichtet ist.
Vielleicht bräuchte man auch eine Art Briefträgerklasse, der ausschließlich Nachrichten entgegennimmt und sie an den weitergibt, der sie braucht.

Ja, ich hoffe halt da auf sowas Ähnliches wie Eventlistener und Eventsender (falls es letzteres überhaupt gibt).
Klar ist das Overengineering.
Manchmal wäre es auch shcon nice wenn auf eine Frage wie "Wie macht man A in Java" nicht dauernd Antworten käme a la "Pff, das geht doch viel einfacher, was willst du denn machen? Erzähls uns den Sinn des Lebens und dein leben von Anfang bis Tod".
Sondern vielleicht einfach ein "Das kann man mit der X API machen oder Java hat diese oder jene Klasse dafür" oder so.

Wie im obigen Beispiel, selbst wenn man es mehrzeilig mit entsprechenden "Zwischenobjekten" schriebt, diese Verbindung bleibt.

Das Ganze Programm ist eine Folge von Schritten, wo ein Schritt erst gemacht werden kann wenn der vorherige zu Ende gemacht ist.
Oder wo eine Methode a(), die eine Methode b() aufruft, erst "fertig" ist (aka returnt) wenn b() fertig ist.

Falls b() dann noch c() und c() d() aufruft, dann darf a() bis ans Ende seiner Tage warten bis es mal fertig ist und das Gesamtprogramm nach der Beendigung von a mal noch was Anderes machen kann.

Diese sequentiellen Abhängigkeitenbeziehungen "a kann erst was Anderes machen wenn der Beauftragte b fertig ist" stören mich.

So wie beim Shcmieden der Minenarbeiter auch nicht ein Stück Erz schürft und dann Tage wartet bis von 20 Zwischenstationen das hin zu nem Schwert verarbeitet wird bevor er weiter schürft.

Nein, er schürft er einen Erzbrocken, wirft ihn auf einen bestimmten Haufen und damit hat er mit dem bestimen Erzklumpen nichts mehr zu tun.
Er muss auch nicht auf irgendwelche Ereignisse warten oder gar sich Gedanken machen welchen Pfad diese Erz noch im laufe seines Dasein nehmen wird.
Er schürft direkt den nächsten Erzklumpen, er wird da nicht durch Abhängigkeiten und Co. zu zwangswarten verpflichtet.

Und die anderen Anwesenden (Schmied und Co.) , wenn sie nicht noch iNA rbeit sind, sitzen da und hören das Event "Neuer Erzklumpen auf dem haufen!" und der, der mit erz was anfangen kann, geht hin und holt ihn sich und beginnt mit der Arbeit.

Wie halt Eventlistener und Eventtriggerer, nur halt zwischen Objekten und nicht zwischen Server/Client oder sowas.

 

[Neumi5694]

Manchmal wäre es auch shcon nice wenn auf eine Frage wie "Wie macht man A in Java" nicht dauernd Antworten käme a la "Pff, das geht doch viel einfacher, was willst du denn machen? Erzähls uns den Sinn des Lebens und dein leben von Anfang bis Tod".
Sondern vielleicht einfach ein "Das kann man mit der X API machen oder Java hat diese oder jene Klasse dafür" oder so.

Im Normalfall gibt's diese Antworten, aber keine APIs, weil die Idee Blödsinn ist.

In diesem Fall ist die Antwort aber vielleicht ReactiveStreams.
Kommt ein bestimmtes Objekt an, dann passiert was, dem Empfang eines Objekts einer bestimmten Klasse wird ein Listener zugewiesen.
Es gibt dort dann auch so was wie answer() Methoden (oder send to sender), um an den Sender was zuückschicken zu können, ohne sich weiter darum zu kümmern, um wen es sich eigentlich handelt.

 

[KonradN]

Das Problem ist schlicht, dass der Eindruck entsteht, dass Dir noch ganz massiv der Überblick fehlt. Und Du Dih evtl. in irgendwelche Dinge verrennst ohne überhaupt ein Verständnis von der Thematik zu haben. Und die Erfahrung mit den bisherigen Threads ist da für den, der Antwortet, schon negativ genug - da sind dann Aussagen wie

Manchmal wäre es auch shcon nice wenn auf eine Frage wie "Wie macht man A in Java" nicht dauernd Antworten käme a la "Pff, das geht doch viel einfacher, was willst du denn machen? Erzähls uns den Sinn des Lebens und dein leben von Anfang bis Tod".

aus meiner Sicht nicht hilfreich und eher demotivierend. Denn diese Nachfragen kommen ja nicht, weil Wir Dir nicht helfen wollen sondern weil wir eben nicht glauben, dass eben genau so eine Antwort:

"Das kann man mit der X API machen oder Java hat diese oder jene Klasse dafür"

nicht weiter helfen wird.

Denn Du brauchst keine spezielle API. Das Java Framework hat schon prinzipiell alles drin! Und das, was Du so formulierst von wegen "Briefträgerklasse". Sowas wäre ja - wenn man das wirklich wollte, trivial zu bauen.

Falls b() dann noch c() und c() d() aufruft, dann darf a() bis ans Ende seiner Tage warten bis es mal fertig ist und das Gesamtprogramm nach der Beendigung von a mal noch was Anderes machen kann.

Aber genau das ist ja die Anforderung.

Beispiel mit dem Auto bauen: Wenn ich Dr sage: "bau mir ein Auto", dann musst Du halt erst Motor, Räder, Karosserie, .... haben. Und erst wenn Du alle Bauteile hast, kannst Du das Auto bauen und mir geben. Das was Du hier also beschreibst ist as, was man als Asynchron bezeichnet:
Ich bestelle das Auto bei Dir. Aber natürlich warte ich dann nicht, bis das Auto kommt. Ich schicke die Bestellung ab und danach mache ich dann andere Dinge. Und von Zeit zu Zeit prüfe ich dann: Ist das Auto denn geliefert worden?

Und wenn Du nach dem Lesen meiner Antwort Dir etwas den Namespace mit den Klassen angesehen hättest, dann hättest Du z.B. gesehen, dass Du dann Future Instanzen hättest, die Du diesbezüglich nutzen könntest.

Zu diesem Thema gibt es aber sehr viel Dokumentation, die man lesen könnte.... einfach einmal eine kleine Hand voll Links, die mir Tante Google mal eben schnell gegeben hat:

Asynchronous Programming in Java | Baeldung

Learn about a few ways to achieve asynchronous programming in Java

www.baeldung.com

Async in Java

A tell-all guide to understanding the function

www.cognizantsoftvision.com

Speziell mit Callbacks:

Asynchronous and Synchronous Callbacks in Java - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

www.geeksforgeeks.org

Nein, er schürft er einen Erzbrocken, wirft ihn auf einen bestimmten Haufen und damit hat er mit dem bestimen Erzklumpen nichts mehr zu tun.
Er muss auch nicht auf irgendwelche Ereignisse warten oder gar sich Gedanken machen welchen Pfad diese Erz noch im laufe seines Dasein nehmen wird.
Er schürft direkt den nächsten Erzklumpen, er wird da nicht durch Abhängigkeiten und Co. zu zwangswarten verpflichtet.

Aber derjenige, der 1T Erz haben will, der muss so lange warten, bis 1T Erz bereit stehen. Ich muss so lange warten, bis mein Auto fertig ist. Das ist der entscheidende Punkt.

Wenn man das jetzt so wieder liest: Das sind einfache Producer / Consumer Zusammenhänge. Es gibt einen Eisenerz-Consumer und es gibt einen Eisenerz-Producer. (Oder jeweils mehrere). Aber wo ist da Dein Problem?

Zwei Threads: Einer erzeugt Erz und liefert es in ein Lager. Ein anderer entnimmt das Erz dem Lager. Wenn das Lager voll ist, legt sich der Producer schlafen. Wenn das Lager leer ist, dann legt sich der Consumer schlafen. Und damit beide mit Ihren LKWs nicht zusammen stoßen gibt es eine Automatik, dass nur einer mit seinem LKW in das Lager darf.

Das sind einfache 08/15 Zusammenhänge. Solltest Du im Studium auch schon gelernt haben. (Du studierst das doch oder aber ich das falsch in Erinnerung? Ja, dieses komische Zeug, das Du dann immer wieder vergessen musst so sehr, dass Du Dich nicht mal mehr an die Themen einer Vorlesungerinnern kannst ... oder verwechsel ich Dich mit jemand anderes?) Du brauchst für solche Dinge keine Libraries. Das sind Dinge, die sich relativ einfach selbst bauen lassen. (Die Libraries haben natürlich auch Ihren Sinn. Denn mit der Zeit will man immer mehr Features und so. Und das baut man sich dann nicht mal eben so.)

Und du erkennst: Nur auf Grund Deiner Äußerungen habe ich jetzt schon drei Unterschiedliche Dinge als das identifiziert, das Du evtl. willst: Asynchrone Aufrufe, so eine Art "Briefträger" und das mit dem Producer/Consumer. Es ist also durchaus wichtig, dies genauer zu spezifizieren bzw. für uns da nachzufragen, was Du überhaupt willst.