Klassen objektorientiert aufteilen

[Caliburns]

Hallo,

ich habe eine grundlegende Frage zum Trennen von Klassen, aber der Beibehaltung einer Objektorientierten Modellierung.

Angenommen ich habe eine Main-Klasse in der ich ein Objekt graph der Klasse Graph erzeuge. In der Main-Methode kann ich ja dann über graph.tueEtwas() die Methoden aufrufen. Allerdings schwillt mir die Klasse Graph mit vielen Methoden dermaßen an, dass ich diese Klasse aufteilen möchte. Jedoch in der Main ganz normal weiterhin über graph.tueEtwas() Zugriff auf die ausgelagerten Methoden haben will.

Wichtig: Die Klasse Graph enthält bei mir diverse Listen auf die ich mit den ausgelagerten Methoden weiterhin objektorientiert zugreifen möchte (quasi so, als wären sie überhaupt nicht ausgelagert).

Gibt es hierfür eine Möglichkeit Methodenauslagerungen ohne großen Aufwand vorzunehmen?

Für die Hilfe Vielen Dank!

 

[M.L.]

Man könnte die Methoden in Interfaces auslagern. Aber bei SO gibt es Alternativvorschläge: https://stackoverflow.com/questions...a-method-function-from-another-class/26269220

 

[temi]

Die Klasse Graph enthält bei mir diverse Listen

Evtl. mal drüber nachdenken, ob man für jede der Listen eine eigene Klasse erstellt.

Ohne weitere Infos ist zu deinem Problem nicht viel mehr zu sagen. Man sollte vermeiden sogenannte Gott-Klassen zu erstellen, aber das hast du ja selbst schon bemerkt. Eine Klasse sollte nur eine klar umrissene Aufgabe haben.

 

[Caliburns]

Ich habe mir nun überlegt, alle Befehle die eine Ausgabe von den Listeninhalten erzeugen in eine separate Klasse "Printer" auszulagern. In der Main erzeuge ich neben dem Graph-Objekt auch ein Printer-Objekt, das das Graph-Objekt als Parameter bekommt. Das Printer-Objekt kann nun auf die Listen im Graph zugreifen und ausgeben. Dadurch spare ich einiges an Platz und es ist nach wie vor objektorientiert. Außerdem sind die Aufgaben dann nochmal klarer definiert.

 

[temi]

Kannst du evtl. grob beschreiben, was die Klasse Graph genau enthält und welche Methoden benötigt werden?

"Objektorientiert" ist ja so ein Begriff. Wenn du eine Klasse mit allem drin hast, dann ist es auch noch objektorientiert, es gibt halt ein Objekt. Das heißt nicht, dass es gutes Design ist.

Aber es ist quasi eine Grundregel, dass man das UserInterface ("die Ausgabe") von der Logik trennt. Du bist demnach auf dem richtigen Weg.

 

[mihe7]

Wenn du eine Klasse mit allem drin hast, dann ist es auch noch objektorientiert

Eher: manche glauben, Objektorientierung bestünde darin, Code in eine Klasse bzw. in Klassen zu packen

 

[kneitzel]

Mein Tipp wäre hier jetzt ein Buch: "Object Thinking" von David West erschienen 2004 bei Microsoft Press.
Lässt sich sehr gut lesen und aus meiner Sicht vermittelt es einen sehr guten Einstieg in diese Thematik. Muss man auch nicht extra kaufen - ich würde schauen, ob man es nicht einfach ausleihen kann - ggf. per Fernausleihe oder so.

Ansonsten müsste man etwas mehr erfahren, was da Dein Objekt macht und was es da für Bestandteile gibt. In der Regel gibt es klare "Schnittlinien", die man zur Unterteilung nutzen kann und die man mit etwas Übung relativ gut sehen kann.

Das ist dann wie ein technisches Gerät - das setzt sich aus kleinen Bausteinen zusammen. Und bei der Bedienung hat man dann - wie schon angesprochen - oft Interfaces.

Beispiel wäre dann z.B. ein toller BMW. Du hast ein BMW gekauft. Und der setzt sich aus vielen Bauteilen zusammen. Er hat z.B. einen Motor. Der Motor hat dann aber wieder diverse Bauteile: Zylinder, Dichtungen, Ventile, ...
Und von der Bedienung hat er klare Interfaces. Es ist ein Auto mit manueller Gangschaltung. Du hast gelernt, sowas zu fahren. Daher kannst Du auch den BMW fahren. Ebenso wie jedes andere Auto, das so ein Interface anbietet.

Und es gibt viele Interfaces. Das "Auto Fahren Interface" ist ja nur eines. Viele brauchen das aber nicht. Wenn Du Kinder hast, dann willst Du denen das nicht geben. Dann haben die ein eigenes Interface das dann diverse Dinge ermöglicht. Das "Einsteigen und Anschnallen Interface" würde mir da pauschal einfallen

Mit dem Beispiel haben wir schon einige wichtige Aspekte direkt behandelt ohne es wirklich zu merken:
- Abhängigkeiten haben wir rausgenommen. Wenn Du ein AutoMitGangschaltung fahren kannst, dann bist du unabhängig von BMW oder so. Du kannst jedes Auto fahren.
-Kapselung - Du nutzt das Interface. Da ist es Dir relativ egal, was intern passiert. Ob da nun ein Diesel (Selbstzünder), Benziner (aktive Zündung), Elektromotor, .... innen drin ist, ist dir erst einmal egal wenn du das Fahrzeug fahren willst. (Aber es gibt durchaus Interfaces, wo das eine Rolle spielt.... man denke nur ans Tanken ....)

Und man sieht auch viele Dinge, die wichtig sind: So schleifst Du in der Regel keine Interfaces 1:1 durch. Motor -> Drehzahl erhöhen ist natürlich wichtig. Und das macht der Fahrer ja auch mehr oder weniger. Aber es wird das Auto bedient und da ist es dann ein beschleunigen. Das kann 1:1 ein Aufruf beim Motor sein, aber dem muss ja nicht so sein.

Aber da bin ich jetzt viel zu weit gegangen. Das findet sich alles bestimmt auch auf Webseiten deutlich besser beschrieben ... oder eben auch in dem erwähnten Buch....