"Firmenhierarchie" in Java umsetzen?

[berndoa]

Hallo, ich will mein ehemaliges Roulettebot Hobbyprojekt etwas runderneuern und neu machen.
Dazu will ich gewissermassen wie in einer Firmenhierarchie mit verschiedenen Parteien und deren Beziehungen untereinander arbeiten.

Konkret stelle ich mir also sowas vor wie:
Ganz oben
Ganz oben ist ein GameflowManager, als "Kinder" in der Hierarchie hat dieser einen Login-, Maingame- und einen Exitmanager.
Bspw. der Maingamemanager hat unter sich dann wiederum einen Einsatzmanager, Colormanager, Moneymanager und ggbfls. andere mehr, die vielleicht noch dazu kommen.

AUch Loginmanager und Exitmanager haben vermutlich noch gewisse Lemminge unter sich.

Und wie halt auch logisch, kennt jede Position zum einen den (einzigen) Boss obndrüber, kennt die gleichgestellten (also loginmanager kennt auch maingame und exitmanager und umgekehrt, wiel auf gleicher Ebene und alle gleichen boss).

Sowie jeder kennt natürlich seine direkten kinder.

Das Prinzip würde ich gerne in Javacode umsetzen und für jede Position eine Klasse bauen.

Hierbei will ich in der Theorie wie folgt vorgehen:
Bspw. baue ich eine GameflowManager(der big boss ganz oben) Klasse, die bei den Attributen erst mal sowas stehen hat wie

public class GameflowManager{
    LoginManager loginmanager;
    MaingameManager maingamemanager;
    ExitManager exitmanager;

}

Also erst mal alle mit ihr verbundenen Positionen "angedeutet", wobei noch keine bestimmten Objekte hinterlegt sind.
Für jedes dieser Attribute kriegt die Klasse eine Set und eine Get Methode, wobei es hier natürlich Klasse wäre, wenn man hier das ganz generisch bauen könnte.
Würde mir da sowas vorstellen wie

public void set(T t){
    this.t=t;
}

wo die Method aufgerufen werden kann und statt t eben ein Loginmanagerobjekt oder eins der anderen eingesetzt werden kann.

Kann man das irgendwie so allgemein machen ohne dass ich für jedes Attribut eine identische Methode schreiben muss?


Dann will ich hingehen und Folgendes machen:
Für jede der Klassen will ich den Code der Art

set(new Loginmanager());
loginmanager.set(this);

ausführen.
Wo also erst eine Verbindung zu einer neuen Unterklasse (nicht im Javasinn, im Hierarchiesinn!) hergestellt wird.
Und über diese verbindung dann in der Unterklasse eine Verbindung zur Chefklasse hergestellt wird.

dann hat letztlich die GameflowManager klasse eine Verbindung zur Loginmanager klasse mittels objektreferenz und umgekehrt, die beiden "kennen sich" nun.
gleiches m,it den anderen mitarbeiter-chef-beziehungen.


Nur schwierig wird es nun für mich gerade bei den Bezoehungen auf gleicher Ebene, wie mache ich die?
Denn wenn ich bspw.
in der loginmanagerklasse bin und würde da eine verbindung zu einem neuen exitmanager hrstellen, dann hätte ich ja einen exitmanager, der sich von dem unterscheidet, den der gameflowmanageross kennt.
hätte also unnötig 2 verschiedene exitmanager.

wie mache ich das?

ich vermute, dass ich an das benötigten objekt über den boss und dessen beziehungen nahc unten drankommen müsste, aber wie?

Kann mir da Jemand helfen, das Ganze hinzukriegen ohne irgendswie objekte doppelt zu erzeugen oder falsch zuzuordnen?

 

[KonradN]

Ich sehe da gerade ehrlich gesagt nicht, worauf zu hinaus willst. Der Ansatz ist extrem verworren.

Wenn Du ein Programm schreibst, dann gibt es zwei Dinge, die wichtig sind:
a) die zugrunde liegenden Daten
b) Funktionalitäten auf den Daten

Bei deiner Beschreibung: Du kannst diese Strukturen als Daten ansehen wenn Du möchtest. Dann müsstest Du die aber abstrahieren um universell diese zu beschreiben.
Das wäre in der Firma typischerweise sowas wie eine Klasse Mitarbeiter. Diese haben dann sowas wie:

• Eine ID / Nummer
• Name
• Rolle
• Vorgesetzter

Damit kannst Du es dann universell beschreiben.

Aber mir scheint eher, dass es Dir um Funktionalitäten geht. Du willst da etwas sauber trennen, so dass es Bereiche gibt, wie z.B. einen separaten Bereich, der für Logins zuständig ist. Das kann man unterschiedlich tief unterteilen.
1. Man kann Funktionalitäten einfach in Klassen unterteilen. Eine Klasse braucht dann die notwendigen Instanzen. Das ist dann der einfache OO Ansatz aber je nach verwendeten Frameworks gibt es da dann unterschiedliche Elemente, die da ins Spiel kommen können. Aber vieles kann dann auch direkt als Verhalten in die einzelnen Klassen kommen.
2. man kann dies alles auch noch deutlich stärker aufteilen und dann nur noch eine Kommunikation über ein festes Protokoll zulassen. Jeder Teil verwaltet seine Daten selbst - unabhängig von den anderen Teilen. Da würde man dann z.B. zu diesem Microservice Ansatz kommen.

Aber von Deiner Fragestellung her ist klar: Bei Dir sollte es erst einmal um die Grundlagen gehen. Also noch nichts mit Microservices sondern erst einmal die Grundlagen hin bekommen.

Wenn Du Instanzen hast, die Abhängigkeiten haben zu anderen Instanzen, dann gibt es zwei wichtige Ansätze:
a) Es gibt eine harte Abhängigkeit und die eine Instanz hat dann die Referenzen zu den anderen Instanzen. Beispiel: Auto:
Ein Auto hat einen Motor, 4 Reifen .... Und genau das bildet man dann ab:

public class Auto {
    private Motor motor;
    private Rad[] raeder = new Rad[4];
}

Diese Dinge müssen dann gesetzt werden. Je nachdem, was Sinn macht oder nicht, gibt man sowas direkt beim Konstruktor mit. Oder man hat Methoden, die das machen. En Auto ohne Motor macht keinen Sinn. Der ist sofort drin. Also gibt es einen Konstruktor, der den Motor als Parameter bekommt. Räder werden aber dann erst montiert, denn da will ja jeder was anderes .... Je nach Jahreszeit halt Winter, Sommer oder Alljahresreifen ... und evtl. ganz teure gute oder lieber die günstigen? Daher gibt es da nur einfache Methoden.

b) Je mehr Abhängigkeiten es gibt, desto komplexer wird es. Daher gibt es Techniken, diese Abhängigkeiten aufzulösen. Ein erster Schritt ist halt, dass. man ggf. nur Interfaces verwendet. (Motor ist ein Interface und man kann da diverse Benzin oder Dieselmotoren verwenden). Das reicht aber nicht, denn man hat oft keine Instanz zur Hand und will das auch nicht. Es interessiert einfach nicht, was passiert.

Beispiel: Eine Maschine produziert etwas. Was mit den Teilen weiter passiert, ist der Maschine doch egal. Ob die fertigen Teile einfach in einen Behälter fallen oder ob da ein Fließband ist. Oder ein Mitarbeiter nimmt die Teile. Oder ein Roboterarm ... das ist vollkommen egal. Die Maschine stellt die fertigen Teile einfach bereit.
Das kann man dann als Observer Pattern implementieren. Die Maschine stellt nur eine Information bereit: Teil fertig. Es kann dann aber Beobachter geben, die darauf nur warten. Also ein Mitarbeiter wartet darauf, dass die Maschine signalisiert: Teil fertig - um dann eben mit dem Teil etwas zu machen. --> Die Maschine ist komplett unabhängig von den weiteren Schritten.

Generell sollte man also immer versuchen, seinen Code aufzuteilen. Da gibt es dann auch eine ganze Menge Möglichkeiten, die als Pattern beschrieben wurden. Hier kann man also nur empfehlen, sich das einmal im Detail anzusehen --> Buch "Entwurfsmuster von Kopf bis Fuß"

Das alles kann man recht gut aufbauen:
So kannst Du eine Klasse Applikation haben, die dann alle wichtigen Dinge kennt. Die Applikation kennt also den "LoginController", den "GameController", ....
Die Applikation könnte jetzt also dafür zuständig sein, diese Controller zu erzeugen. Die Applikation könnte sich selbst bekannt geben. Dann haben alle Controller eine Referenz auf diese Applikation. Und die Applikation kann dann die Instanzen auf Anfrage auch weiter geben.

Das wäre dann ein ganz einfacher Ansatz, den man nutzen könnte.

Das ist dann auch etwas, das man stark automatisieren kann. Das ist dann das, was man als Dependency Injection (DI) und Inversion of Control (IoC) bezeichnet: Wenn eine zentrale Stelle verantwortlich ist, dann kann man das ja evtl. automatisieren. Dann muss man für die ganzen Controller nicht immer das gleiche machen: Instanzvariable, Getter, (bei Bedarf) eine Initialisierung, ...
Das wären dann entsprechende Frameworks wie z.B. Spring Boot. Diese Scannen dann die Klassen und schaut, ob einzelne Klassen gekennzeichnet wurden. Gekennzeichnete Klassen werden weiter analysiert: Diese werden halt vom Framework erzeugt und initialisiert und dazu wird geschaut, was dafür notwendig ist.
Alternativen zu diesem Scannen gibt es natürlich auch - sowas kann z.B. auch in einer Konfigurationsdatei beschrieben stehen.
Das aber nur als ein Ausblick - der einfache Ansatz ist, dass man eine zentrale Klasse hat und die verwaltet die wichtigen Elemente und erzeugt diese auch.

 

[berndoa]

Ich stelle mir das bspw wie in einer Autofirma vor:
Es gibt einen Bigboss, der Alles überwacht, mal von hier und da Rückmeldungen kriegt und Befehle verteilt.
Dann gibts direkt darunter ne Marketingabteilung, eine Reifenabteilung, eine Karosserieabteilung, etc.
Und direkt unterhalb der Reifenabteilung gibt es dann Alles Mögliche, was zur Reifenbauen nötig ist.
Bspw. mitarbeiter 1,2,3 ; einen Roboter, etc.

Halt eine Hierarchie, wo jedes Glied (abgesehen von Bigboss ganz oben) genau einen Chef hat, aber unbegrenzt Leute unter sich haben kann.
"Pyramidensystem" sozusagen
Bzw. wie ein Binärbaum, nur halt mit auch mal mehr oder weniger als 2 Kindknoten.
So bspw. wie in diesem Bild hier:

https://www.ionos.de/startupguide/fileadmin/StartupGuide/Screenshots_2018/DE-funktionale-organisationsstruktur.png

Mein Roulettebot besteht ja erstmal aus einer Loginphase, einer Hauptphase und einer Exitphase.

Darum will ich ein Mainklasse haben, die Alles von Anfang bis Ende überwacht.
Darunter, hierarchisch gesehen, dann für jede Phase eine Klasse, die mit der Mainklasse in Verbindung steht.

Am Anfang sendet die Mainklasse der Loginklasse eben eine Message "Yo, mach Login, Junge!".

Dann macht die Loginklasse ihr Ding und gibt ihrem Boss die Meldung zurück, dass der Login fertig ist.
Nahc Erhalt der Nachricht benachrichtigt die Mainklasse dann die Hauptphasenklasse, dass die loslegen soll.
von dort wieder nachricht zurück, dann wird die exitphasenklasse beordert.

Natürlich macht bspw. gerade die Hauptphasenklasse nicht Alles selbst sonder n hst wieder Leute unter sich die es mit gesendeten und erhaltenen Befehlen dirigiert.
Also bspw. Jemand fürs Moneymanagement, ein Farbenmanager, ein Buttonmanager, etc.

Wenn bspw. der Buttonmanager gemäß Befehl von oben seinen Knopf gedrückt hat, wird dies direkt oder indirekt dem Farbenmanager mitgeteilt und der tut das nötige, um die gerade gedrehte Farbe rauszufinden.

Der eine Mitarbeiter schickt also sein "Ergebnis" (und seis nur die tatsache dass er den Drehbutton gedreht hat und nun der Farbenmanager eben die Ergebnisfarbe updaten soll) an seinen Kollegen vom Farbenmanagement.


Nur wie man nun die gamnze Kommunikation bei dem ganzen hinkriegt, weiß ich nicht.

Wie jeder im "Unternehmen" nun wissen kann oder soll wer welche Methoden hat, ist auch die Frage.
Also bspw. wenn der Typ, der bei der Hauptphase den letzten Arbeitsschritt gemacht hat, nun wissen soll wer im Ablauf nun sein Nachfolger in der Exitphase ist, ist die große Frage.



Oder rein theoretisch könnte auch jede klasse/objekt nach beenden einer methode hingehen und sein Endergebnis ("Würfel wurde geworfen" oder "Das Würfelergebnis war 3!" oder so), insofern er nicht eine eigene methode zum verwerten hat, an seinen vorgesetzten und dmait im baumdiagramm nach oben zum elternknoten schicken.
so lange bis die botschaft beim big boss, dem wurzelknoten , angekommen ist.

und der müsste, durch göttliche fügung oder so, wissen entlang welchen pfades im baumdiagramm es wieder zu shcicken ist um bei dem knoten irgendwo im diagramm anzukommen, der als nächstes die nachricht braucht und verarbeitet.
müsste also an sich jeder knoten wissen, welche methoden in jedem seiner kindbäume zu finden sind. oder so.

oder es gibt einen für jeden zugängliche "lookup table" wo eben drinsteht "methode1: klasse7, methode2: klasse4, usw."

Keine Ahnung wie mand as umsetzt. Oder ob ich da einfach das hierarchie/baumdiagrammprinzip zu srg in java umsetzen will und java dafür einfahc nicht so recht geeignet ist :-(

Natürlich könnte man auch mit tiefen oder breitensuche einbfach jeden knoten im baum durchguckn um zufällig, früher oder später, den einen zu finden der die benötigte methode hat.
was halt jedes mal sehr zeitintensiv ist bei jedem methodenaufruf :-(

 

[KonradN]

Für mich klingt das relativ wirr. Es geht nun einmal nicht um ein "überwachen" sondern um eine Zusammenarbeit.

Also nix Kontrolle. Und wenn Du einen Mitarbeiter als Klasse hast, dann mag es eine NichtsMachenderlMitarbeiter Implementation geben, der halt nichts macht.
Der zeichnet sich dadurch aus, dass er Aufgaben entgegen nimmt und zurück meldet, dass diese erledigt sind ohne irgendwas gemacht zu haben.
Das mag aus Deiner Sicht nicht die Erwartung an einen Mitarbeiter sein, aber das ist ein gültiger Mitarbeiter ... Aber halt einer, der nichts macht - so wie der Name schon suggeriert.

Daher ist alles weiterhin nur eine Unterteilung in Teilaufgaben und damit eine sinnvolle Strukturierung.

Aber das habe ich bereits in der ersten Antwort beschrieben. Und ich meine, dass wir dazu schon einige Threads hatten. Im Augenblick sehe ich keinen Ansatz, wie ich Dir da gerade weiter helfen kann. Nur so offensichtliche Dinge kann man aufzeigen.