Wie geht eigentlich Objektorientierung?

[Hag2bard]

Hallo,

Ich bin mit meinem größeren Projekt, welches ich gerade erstelle recht zufrieden. Mein Code ist lesbar, wartbar und erweiterbar.
Allerdings habe ich das Gefühl dass ich, was die Objektorientierung angeht, ziemlich Bullshit anstelle.
Ich weiß nicht wie ich mit Objektorientierung umgehen soll.
Die ganze Theorie vermittelt mir nicht das Wissen welches ich benötige um das ganze in der Praxis umzusetzen.
Ich habe folgende Klassen (die für dieses Beispiel relevant sind):

Die Klasse Pokeeditor2 die Objekte von den Klassen Logic, TilePanel, MapPanel erstellt.

Die Klasse Logic, die auf das Objekt von Pokeeditor2 und das TilePanel Objekt zugreifen muss.

Die Klasse TilePanel, die auf das Objekt von Pokeeditor2 zugreifen muss

Die Klasse MapPanel die auf die Objekte TilePanel, Logic, Pokeeditor2 zugreifen muss

Mein Workaround ist folgender: Ich habe eine Klasse ObjectPlace, die bei der Erstellung der jeweiligen Objekte diese übergeben bekommt.
Wenn ich z.b. von MapPanel auf TilePanel zugreifen muss mache ich das so:

objectPlace.tilepanel.methode();


Alles was ich möchte funktioniert so, aber ich glaube das ist Käse.
Wie würdet ihr das umsetzen?

Danke im Voraus Chris

 

[Neumi5694]

"Workaround" ... wofür?

objectPlace.tilepanel.methode();

So hoffentlich nicht, das würde ja bedeuten, dass tilepanel public ist. Public Variablen sind ein Nono.

Wenn ein Objekt auf die Eigenschaften seines "Besitzers" (nennen wir's mal so) zugreifen muss, dann ja: Dann musst du dem Objekt erst mal sagen, wer sein Besitzer ist, entweder direkt im Konstruktor oder per set-Methode.

//Klasse PokeEditor2
public Pokeeditor2() {
    this.logic = new Logic(this);
}
//Klasse Logic
public Logic(Pokeeditor2 owner) {
   this.owner = owner;
   this.owner.getTilePanel().doSomethingImportant(). //Der Zugriff im Konstruktor dient nur als Anschauungsbeispiel. Grundsätzlich ist es besser, jetzt noch nicht darauf zuzugreifen, sondern die Parentklasse erst mal die Initialisierung beenden lassen.
}

 

[temi]

Ich würde dir das Buch "Entwurfsmuster von Kopf bis Fuß" ans Herz legen. Das wird viele deiner Fragen beantworten.

Aber was Objekte an geht: "Dinge" die eine Instanz benötigt sollten über den Konstruktor übergeben werden. Nach dem Erzeugen der Instanz, sollte sie "arbeitsfähig" sein.

Wenn also die Klasse TilePanel auf den PokeEditor zugreifen muss, dann mit TilePanel tp = new TilePanel(pokeEditor);. Damit kennt tp den pokeEditor und kann damit arbeiten.

Und in der main() "baust" du das zusammen. Hier mal beispielhaft:

public static void main(String[] args) {
   
    Player playerOne = new Player("Hans");
    Player playerTwo = new Player("Fritz");
   
    Playground playground = new Playground(playerOne, playerTwo);
   
    playground.startGame();
}

 

[Hag2bard]

Meine Variablen sind schon gekapselt aber meine Methoden nicht, von daher fande ich es ziemlich unübersichtlich die Objekte hin und her zu schieben. Ich werde mir das Buch Entwurfsmuster nochmal zu Gemüte führen, vielleicht hilft es mir ja weiter.

 

[Neumi5694]

Meine Variablen sind schon gekapselt aber meine Methoden nicht, von daher fande ich es ziemlich unübersichtlich die Objekte hin und her zu schieben. Ich werde mir das Buch Entwurfsmuster nochmal zu Gemüte führen, vielleicht hilft es mir ja weiter.

Was ist denn eine nicht gekapselte Methode im Gegensatz zu einer gekapselten?

Natürlich musst du Referenzen auf Instanzen für denjenigen verfügbar machen, bzw. an den übergeben, der sie verwendet. Wie soll das denn sonst gehen?
Nur bei statischen Methoden reicht die Angabe der Klasse ohne Instanzvariable .

 

[Hag2bard]

Wahrscheinlich hab ich mich da blöd ausgedrückt, ersetzen wir einfach gekapselt durch Private. Ich mach immer alles was möglich ist privat und hole oder verändere die Werte durch getter und setter aber die Frage ist wie ich die Objekte verfügbar mache. In einem kleineren Projekt hatte ich dann teilweise schon einen Aufbau wie folgendes Beispiel.

klasse4.klasse3.klasse2.doSomething();
Also verkettet ohne Ende.

Dann hatte ich einen Aufbau, bei dem ich mit einem ganz wildem Aufbau an gettern und settern die Referenzen auf die Instanzen weiter gegeben habe, bis jede Klasse die die Objekte brauchte diese auch bekam. Das fande ich aber ziemlich unsauber. Nun habe ich eine zentrale Sammelstelle für Instanzen mit Settern und Greif dann von egal welcher Klasse auf z.b. die TilePanel Instanz so hier zu:

objectPlace.tilePanel.doSomething();

Natürlich muss ich mich drum kümmern dass jede Klasse die Zugriff auf Instanzen anderer Klassen braucht, die Instanz von objectPlace kennt. Aber das ist weniger aufwändig als beim Hinzufügen einer neuen Klasse soviel umzumodeln. In dem aktuellen Projekt spielt es wahrscheinlich keine Rolle, aber wenn ich Anfang Februar dann das erste mal vor richtigem Java Code sitze ist es vielleicht schon zu spät. Wobei ich natürlich richtig ausgebildet werde und mich bei fertigem Code auch an dessen Struktur richten muss. Aber für Privat weiß ich nicht welchen Weg ich gehen muss.

 

[kneitzel]

So Verkettungen deuten in der Regel darauf hin, dass etwas schlecht geschnitten ist bzw. Funktionalitäten nicht gekapselt wurden.

Wenn Du in Klasse4 auf eine Instanz von Klasse3 zugreifst, dann darf es für die Klasse4 nicht von Interesse sein, wie die Klasse3 das intern macht. Ob da nun eine Klasse2 verwendet wurde oder nicht ist absolut nebensächlich!

Wenn die Klasse 4 etwas von der Klasse 3 braucht, dann muss die Klasse 3 das liefern. Dann kann die Klasse 3 intern natürlich auch auf Klasse 2 zurück greifen. Aber das kann auch ganz anders erfolgen! Wenn Du sowas nicht sauber trennst, dann wird dein Code unwartbar! Stell Dir vor, Du willst Klasse 3 ändern und statt Klasse 2 soll nun eine andere klasse intern verwendet werden. Und nun hast du ganz viele Klassen, die davon abhängen so wie die Klasse 4!

Also Beispiel Auto: Du greifst nicht direkt auf Internas des Motors zu! Der Motor hat eine Schnittstelle und die sprichst Du an. Du kannst also Gas geben und so. Aber du fängst nicht an, die Ventile direkt zu steuern. Wenn ein anderer Motor eingebaut wird, dann fliegt Dir alles um die Ohren! Oder es funktioniert erst gar nicht, weil mehr oder weniger Ventile da sind oder diese etwas anders gesteuert werden müssten. Die Internas interessieren das Auto schlicht nicht!

 

[mihe7]

Einfach formuliert, geht es in der OO darum, zusammenzubringen, was zusammengehört und alles andere möglichst strikt voneinander zu trennen.

Daraus folgen dann ganz grundsätzliche Dinge, wie z. B. dass man UI und Fachlogik voneinander trennt. Ein gutes OO-Modell schüttelt man auch nicht mal eben aus dem Ärmel, das muss man entwickeln.

Wenn ich mich recht entsinne, war das dieser TileMap-Editor, bei dem auf der rechten Seite das TileSet und in der Mitte die TileMap angezeigt wurde. Das wären ja schon einmal zwei Komponenten.

Aus der Trennung von UI und Fachlogik kann man wiederum ableiten, dass es zu den Komponenten auch Klassen für die Fachlogik geben muss. Das Schichtenmodell lehrt, dass untere Schichten die höheren realisieren, so dass die höheren Schichten zwar die darunterliegenden kennen, die Umkehrung jedoch nicht gilt. Im Klartext: die UI-Komponenten kennen zwar ggf. Klassen der Fachlogik, die Fachlogik weiß aber nichts von einem UI.

Jetzt kann man sich z. B. überlegen, wie man ein TileSet modelliert (einen Ansatz dazu hatte ich Dir einem anderen Thread gegeben). Das hat nichts mit der UI-Komponente zu tun, die das TileSet anzeigt. Gleiches gilt für die TileMap. Im Prinzip kannst Du so einen TileEditor bauen, der ohne UI funktioniert. Bei allen Klassen etc. gilt der eingangs beschriebene Grundsatz, so dass eine Klasse nicht zu viel vereinen darf.

Mein Code ist lesbar, wartbar und erweiterbar.

Nein. So etwas

klasse4.klasse3.klasse2.doSomething();

bedeutet übelste Abhängigkeiten. Das ist genau das Gegenteil von wartbar.

 

[Hag2bard]

Diese Verkettung hatte ich auch in meiner ersten GUI so durch gezogen und Nein wartbar ist das nicht
Ich werde im aktuellen Projekt erstmal schauen ob ich das ganze nochmal säubern kann, ich weiß nicht ob es meine schlecht selbst beigebrachte Vorgehensweise ist oder ob das vielen Anfängern so geht aber anfänglich war mein Projekt unübersichtlich und ich optimiere es immer mehr in Richtung Sauberkeit und Lesbarkeit. Vielleicht weil ich auch viele neue Vorgehensweise bei einer Gui erst in diesem Projekt kennen gelernt habe.

P.S.: Apropo GUI von Logik trennen. Meine GUI Klasse ist aufgebläht durch Key und MouseListener, sollte ich diese generell auch auslagern?

 

[temi]

ich weiß nicht ob es meine schlecht selbst beigebrachte Vorgehensweise ist

Ja

oder ob das vielen Anfängern so geht

Auch ja

Das ist schon ein Prozess, vor allem, wenn man es sich selbst beibringt.

 

[mihe7]

P.S.: Apropo GUI von Logik trennen. Meine GUI Klasse ist aufgebläht durch Key und MouseListener, sollte ich diese generell auch auslagern?

Es gilt der gleiche Grundsatz: was zusammengehört... da ist gerade im UI so manches Ansichtssache.

Nehmen wir mal ein TileSetPanel. Es ist ja gerade Sinn und Zweck der Komponente, ein Tile auswählen zu können. Insofern spricht hier m. E. nichts dagegen, entsprechende Listener-Implementierungen auch in die Komponente zu integrieren.

Man kann genauso andersrum argumentieren: das TileSetPanel soll das TileSet und eine Auswahl darstellen. Wie die Auswahl abläuft, ist nicht Aufgabe der Komponente.

Aber: in beiden Fällen hätte man eigene (ggf. innere, anonyme) Klassen, es geht also nur darum, wie eng man die Teile aneinander koppelt.

Oft sind Listener auch einfach nur "glue code", der nur eine Methode der Komponente aufruft. Das lässt sich gut mit einem Lambda-Ausdruck oder einer Methodenreferenz realisieren (z. B. submitButton.addActionListener(e -> submit());). Was will man da auslagern?

Wenns komplexer wird und/oder der Code generischer ist, dann lohnt es sich durchaus darüber nachzudenken, die Listener-Implementierungen in externen Klassen unterzubringen. Und wenn man von der Entwicklung von Komponenten weggeht, dann umso mehr.

Wenn man an ein typisches "Hauptfenster" mit "Datei"-Menü denkt, dann hat der Code zum Öffnen der Datei sicher nichts in der Klasse verloren, die das Fenster zusammenbaut.

In dem Zusammenhang: Swing kennt z. B. Action bzw. AbstractAction. Damit lässt sich z. B. dieselbe Aktion im Menü und in der Toolbar unterbringen, wenn man die Action disabled, werden automatisch der Menüeintrag und der Button im Toolbar disabled.

 

[White_Fox]

Ich würde dir das Buch "Entwurfsmuster von Kopf bis Fuß" ans Herz legen.

Ja, ja....unbedingt.

OOP ist schon ein Lernprozess, er ein Weilchen dauert. Ich hab in meinem Projekt bestimmt schon so 5.000 Codezeilen weggeworfen und von vorne angefangen, bis ich eine Struktur hatte die mir gefiel. Dank o.g. Buches wußte ich immerhin schonmal, wie es nicht geht.

Du erfährst in dem Buch schon ein paar verblüffende Kniffe. Das Dekoratormuster z.B. finde ich einfach nur genial.

 

[Hag2bard]

Deine Antwort klingt sarkastisch, welches Buch würdest du mir denn empfehlen?

 

[kneitzel]

Deine Antwort klingt sarkastisch, welches Buch würdest du mir denn empfehlen?

Ich denke, dass dies nicht sarkastisch gemeint war. Das Buch gilt hier im Forum als ein sehr gutes Buch zu Entwurfsmustern. Eine Alternative, die hier im Forum sonst genannt wird, ist mir jetzt nicht bekannt.

Ich nenne oft noch ein paar Bücher - wie "Object Thinking" von MS Press. Das ist ein älteres Buch, das mir sehr gut gefallen hat. Das würde ich heute nicht mehr neu kaufen (!!), aber wenn man es per Fernleihe oder günstig gebraucht oder so bekommen kann, dann wäre es durchaus noch "lesenswert". Da erläutert halt der Autor, wie man objektorientiert denken sollte.

 

[White_Fox]

Nein, das war tatsächlich kein Sarkasmus. Ich finde das Buch wirklich gut.