OOP Kommunikation zwischen Objekten?

[berndoa]

Hallo,
ich habe mal eine grundsätzliche Frage, bitte nichts zu Komplexes erwarten:
Und zwar war es schon oft so dass ich mich in folgender Situation befand:

Es müssen diverse Aufgaben erledigt werden.
bspw. muss Input eingelesen und verarbeitet werden,
es muss anderswo was mit dem Input berechnet werden,
es müssen Objekte erzeugt werden.
Auch muss womöglich was graphisch gemalt werden (GUI Kram halt).

Vielleicht kommt auch noch OCR vor.

Zumindest für mich organisatorisch war es schon immer dann am Sinnvollsten, das Ganze nahc Aufgabengebieten zu ordnen.
Gibt also sozusagen einen Input Manager, einen Math Manager,
GUI Manager, etc.

Halt für jeden Aufgabenbereich Objekt(e) einer Klasse, mit für die Aufgabe relevannten Attributen, methoden, etc.

Muss man sich wie verschiedene Abteilungen und Arbeiter in eienr Firma vorstellen.
A kriegt von rigendwoher Daten, macht was mit.
gibt es an B weiter mit gewissen Anweisungen für den nächsten Schritt.
B mahct was damit, gitbs an C weiter.

C macht was, je nach internen Vorgängen gibt er es an A zurück oder schickts an D weiter.
Kurzum, die Objekte müssen sich untereinander kennen, vielleicht muss D auch mal As Attribut kennen oder gar ändern,
etc.

Fragt sich nur, wie setzt mans um?

In python habe ich da Null problem.
Von jeder Klasse die entsprechenden objekte erzeugt, in Python kennen sich Top Level Objekte automatisch untereinander und
jedes Objekt kann auf die Attribute und Methoden anderer Klassen zugreifen.

Aber wie macht mans in java?

Da müsste ja jedes Objekt Referenzen zu allen anderen Objekten haben (PITA, und ein Alptraum falls ein neues Objekt dazukommt, muss man in allen Klassen Sachen abändern).

Wie regelt man da sowas?
Python ist recht lax mit seinen Regeln, drum kann ich es einfach direkt machen.
Da kann eine Methode in der D Klasse einfach direkt ein ebstimmtes Pbjekt der Klasse A abändern, hardgecoded.

Garantiert kein schöner Stil, aber es klappt.

Aber wie macht mans in Java?
Bitte keine Spezialklassen oder Ähnliches, will das mit dem Standard Equipment von Java umsetzen.
Mehr eigentlich eine Designfrage aber wie setzt man sowas um?

Oder eine weitere Klasse, die alle anderen Objekte kennt und "Aufgaben rumdeligiert"?
Aber da haben wir dann ja endloskaskaden wie
d.machd(c.machc(b.machb(a.macha)))
wenn der Output der Methode einer Methode als Input in der methode einer anderen methode wirken soll.
Geschweigedenn wenn zyklisch Daten hin und hergeschickt werden...

 

[Ullenboom]

Objektorientierung ist wie im Leben: Man kennt sich und bittet etwas zu tun. Im Speicher steht letztlich ein Objektgraph, wo Objekte verbunden sind, die sich kennen.

Jetzt gibt es 2 Fragen:

1. Wie baut man den Objektgraph auf?
2. Will man eine solche Kopplung überhaupt?

Wenn man das möchte, muss man auf externe Libs zurückgreifen (selbst programmieren lassen wir mal besser …).
IoC-Lösungen wie CDI, Spring, Guice sind gut darin, Objektgraphen aufzubauen. So schiebt man die Objekterzeugung an eine zentrale Stelle ab. Natürlich kennen sich die Objekte, die miteinander interagieren dann, das ist auch okay.

Man kann das auch anders sehen und die Dynamik in den Mittelpunkt setzen, dass Objekte andere Objekte bitten, etwas zu tun, aber es nicht wissen sollen, wer genau was macht. Hier kann ein Event-Bus interessant sind, etwas, was man IMO immer bei GUI-Anwendungen einsetzen wird.

 

[KonradN]

Also erst einmal ist die Aufteilung durchaus richtig. Bei deiner Wortwahl habe ich aber etwas gestutzt:

Gibt also sozusagen einen Input Manager, einen Math Manager,
GUI Manager, etc.

Das kann in Ordnung sein, aber das kann auch bedeuten, dass Du da für irgendwelche Teile sowas wie "Gott Klassen" hast. Das sollte man eher vermeiden.

in Python kennen sich Top Level Objekte automatisch untereinander

Das ist etwas, das schrecklich ist. Geht auch prinzipiell in java. (Wieso fällt mir da direkt "Pongo" ein? Oder wie hiess das Tutorial auf YouTube?). Du hast ja auch in Java sowas wie globale Variablen bis hin zu einem:
Ich mache eine Klasse Var und da packe ich lauter public static Variablen rein und die nutze ich dann von überall.

Ja, technisch geht das. Aber das macht man einfach nicht!

Generell scheint es doch schon so zu sein, dass Du bereits eine Unterteilung in Teilbereiche hast. Diese kannst Du dann doch abtrennen. Dann hast Du eine Art Schnittstelle. Du hast also etwas, das liefert xyz. Und Du hast etwas, das verbraucht xyz. Der Verbraucher muss den Erzeuger nicht kennen.

Meine Auto verbraucht das Benzin und hat keine Ahnung, wo das herkommt und wie das transportiert wurde. Und die Raffinerie erzeugt das Benzin, ohne mein Auto zu kennen.
Diese Trennung ist auch wichtig - stelle Dir vor, ich müsste beim Fahren ständig mit der Raffinerie reden oder so... Oder die Raffinerie müsste bei der Produktion ständig bei meinem Auto nachfragen für irgendwas... Wäre doch auch unsinnig.

Statt dessen gibt es allgemeine Schnittstellen. Es gibt Puffer. Die Raffinerie erzeugt etwas und lagert es zwischen. Dann wird es transportiert und dazu werden irgendwelche Techniken eingesetzt. Prinzipiell ist dann egal, ob das Benzin in einen Tank-LKW, in ein Tank-Schiff oder gar in ein Tank-Flugzeug gepumpt wird.

Und das, was es so physikalisch gibt, gibt es auch in der Softwareentwicklung. Da wurde also nichts neues erfunden sondern es wurden nur Abläufe, die es so schon immer gibt, nachgebaut.

Und was gibt es denn dann alles?

Ich baue etwas und das sollst Du kriegen. Ich kenne Dich aber nicht. Was kann es da alles geben?

a) Ich sorge aktiv dafür, dass Du es bekommst. Aber ich kenne Dich nicht, daher kann ich es Dir nicht geben. Also nutze ich ein System, das wir beide kennen. Im realen Leben wäre es also: Ich packe es in ein Paket, gebe es der Post und die bringt es Dir. Sowas gibt es in allen möglichen Formen von relativ einfach (Es gibt einen gemeinsamen Bekannten also z.B. die Kerninstanz der Anwendung, die alle alle kennen und die dann auch alle Teile kennt auf und sage: Hier habe ich etwas fertig. Dann kann die Anwendung schauen, was da ist und es weiter geben) bis hoch kompliziert (Dann gibt es da komplexe Implementationen von "Enterprise Service Bus" wo dann auch viele Features dazu kommen wie Security, Transaktionen, ...).

b) Observer Pattern. Das geht dann in Richtung Event und ist dann auch ähnlich wie bei UIs. Der Button kennt Dein Programm nicht. Du musst den Button auch nicht genau kennen. Aber es gibt ein Event und das willst Du haben. Also sagst Du dem Control: Wenn da der Nutzer dieses Control auslöst, dann möchte ich das hier erfahren. Die Unabhängigkeit ist gegeben. In die eine Richtung ist klar: Die Framework Entwickler kennen Dich und Deine Klasse nicht. Aber auch Du musst den Knopf nicht kennen. Du hast in erster Linie ein Event und da ist egal, ob dies durch ein Knopf, ein Link, ein angeklicktes Panel, .... gekommen ist. Das Control kann einfach gewechselt werden.

c) Generell kann es natürlich auch sein, dass es einfach nur ein komplexes System ist. Dann kennen sich Teile ggf. auch gegenseitig. Das kann vorkommen. Aber da wird dann oft abstrahiert: Du hast also Interfaces. Damit hast Du eine Abhängigkeit zu einem Interface. Eine Komponente braucht also einen Consumer von etwas. Dann ist egal, was das für ein Consumer ist, so lange das Interface Consumer<etwas> implementiert wurde. Umgekehrt kann es die Beziehung auch geben. Aber auch da ist dann nur ein Interface bekannt. Damit hast Du bei der Implementation keine direkte Abhängigkeit zwischen den Teilen (und die wollten wir ja vermeiden)

Das ist nur eine grobe Zusammenstellung. Es gibt viele Möglichkeiten, wie Dinge strukturiert und aufgebaut werden können. Da hilft es bestimmt, sich einmal die gängigen Entwurfsmuster anzusehen.

 

[Jw456]

J

In python habe ich da Null problem

Das sagt mir das du mit Python auch nicht OOP programmiert hast.
Das kann man in Python auch.

 

[berndoa]

Komisch, dass sehen meine Klassen und Objekte dort aber anders...

 

[mihe7]

Wieso fällt mir da direkt "Pongo" ein? Oder wie hiess das Tutorial auf YouTube?

Das Tutorial, dessen Name nicht genannt werden darf. Ich trau mich trotzdem: Pong. Wurde das Video immer noch nicht verboten?!?

Komisch, dass sehen meine Klassen und Objekte dort aber anders...

Vermutlich wollte @Jw456 damit sagen, dass man noch lange nicht objektorientiert programmiert, bloß weil man Klassen und Objekte im Code stehen hat. Umgekehrt braucht man nicht unbedingt eine Sprache, die Klassen oder Objekte kennt, um objektorientiert programmieren zu können.