Stilfrage: Klassen & Methoden

[Frank123134]

Hallo zusammen,
ich bin recht neu in Java und hab steh grad vor nem Stil-Problem.
Situtation: ich hab ne Klasse die recht viele Methoden zur Verfügung stellt -> jede diese Methoden greift auch noch auf Hilfsfunktionen zu... insgesamt, ist das ganze File der Klasse dann so ca 2500 Zeilen lang und dementsprechend unübersichtlich.

Deshalb meine Frage: Kann ich Methoden in ein anderes File auslagern und zwar so, dass sie sich trotzdem wie normale Methoden verhalten?
Also, ich kann ja zum Beispiel für ne große Methode auch ne eigene Klasse im gleichen Pakage erzeugen - dann hab ich zwar bei protected Variable, auch normalen Zugriff auf die Werte der urspünglichen Klasse, aber muss halt dann immer wenn ich die Methode benutzen will, erst eine Instanze erzeugen...
Des find ich irgendwie nicht so schick...

Naja, würd mich auf jedenfall interessieren, wie ihr sowas macht...

 

[Atze]

wenn es wirklich nur hilfmethoden sind, kannst du sie dir doch in eine hilfsklasse auslagern und statisch machen. dann brauchst du dafür auch kein objekt!

 

[Sekundentakt]

Hi,

2.500 Zeilen. Das ist schon ein wahres Monster.
Ich erinnere mich an die Worte eines Linux-Gurus: "Jedes Programm erfüllt nur einen ganz bestimmten Zweck."

Ich würde mal behaupten, Deine 2.500-Zeilen-Klasse ist eine Art "Mädchen für alles".
Schau Dir mal an, welche Methoden Du zu einer logischen Einheit zusammenschließen kannst.
Das erhöht dann auch die Wiederverwendbarkeit deines Codes.

Mach das aber nicht unter der Zielstellung "die Klasse muss kleiner werden", sondern schau auch, dass die Klassen ohne die "Haptklasse" arbeiten können, sonst gewinnst Du auf lange Sicht nicht viel dabei.

Grüße

 

[Frank123134]

Nee, also es ist schon so, dass die Methoden direkt auf die Klassenvariabeln zugreifen müssen, also auch direkt auf Klassenobjekten operieren sollten... Ist nur so, daß ein paar der Methoden aus mehreren Funktionen bestehen z.B. sowas wie initFunction1(), iterationFunction1() ect...
Wollt damit nur zum Ausdruck bringen, dass es einfach sehr viel Code ist...

 

[Frank123134]

Hmm ok... dann schau ich mal ob ich da was auseinanderbauen kann..
Geht halt konkret um ne Baum Struktur, mit Sachen wie insert, delete, search, NNsearch, kNNsearch, RangeSearch ect...
Ich find des gehört da schon alles rein oder?

 

[Sekundentakt]

Ohne sowas mal selbst gemacht zu haben, kann ich Dir da nicht viel zu sagen.

Aber ich würde da in etwa so rangehen:
Welche Objekte gibt's?

Es gibt den Baum als Ganzes.
Der besteht aus Knoten und Blättern.

Würde ich mich noch weiter mit der Materie beschäftigt haben, fielen mir sicherlich noch ein paar Dinge mehr ein.

Jetzt würde ich in etwa so vorgehen:
Der Baum an sich ist nur eine Art Controller. Er bestimmt wann gelöscht, wann eingefügt und wann irgendetwas traversiert wird. Das sind Methoden, die er haben muss, um seine Knoten und Blätter zu verwalten.

Die Knoten verwalten wiederum den Zugriff auf Blätter und haben auch noch weitere Methoden, auf die der Baum bei Suchanfragen zugreifen können muss.
Blätter verwalten die Daten und haben Methoden, auf die ein Knoten und ggf. sogar der Baum zugreifen können muss.

Ich stecke gerade nicht in der Materie, aber ich sehe hier doch schon eine auftrennbare Struktur.

Hilft Dir das weiter?

EDIT: Um noch mal auf das Zitat von oben zurückzukommen:
Der Baum hat nur einen Zweck: Die Verwaltung der Knoten und Blätter.

Wenn Operationen zu komplex werden, zum Beispiel das Einfügen neuer Knoten und Blätter, dann lohnt es sich auch diese in eine eigene Klasse zu implementieren. Der Baum stößt dann lediglich eine Art addNode()-Methode dieser Klasse an und der Rest geschieht dann an anderer Stelle.

 

[Frank123134]

Ja, Baum und Knoten sind schon 2 Klassen...
Also,was man noch machen könnte ist die ganzen Queries auslagere.

Also, daß ich dann sowas in der Art:

public class Tree{
...
}

public class Query{

public static Point NearestNeighborSearch(Tree t, Point p){
....
}


public static LinkedList<Point> RangeSearch(Tree t, Range r){
.....
}
}




Dann kann ich z.B. wenn ich nen Tree t und Point o hab mit Query.NearestNeighborSearch(t, p) die NearestNeighbor-abfrage aufrufen....
Ich denk des mach Sinn..
Vielen Dank!

 

[Frank123134]

Wenn Operationen zu komplex werden, zum Beispiel das Einfügen neuer Knoten und Blätter, dann lohnt es sich auch diese in eine eigene Klasse zu implementieren. Der Baum stößt dann lediglich eine Art addNode()-Methode dieser Klasse an und der Rest geschieht dann an anderer Stelle.

Ja des klingt gut, dabei ist es dann aber üblich die Funktionen in dieser neuen Klassen public static zu machen oder?
Dass man, wie auch schon erwähnt wurde, keine Objekte braucht...

 

[Sekundentakt]

Ja des klingt gut, dabei ist es dann aber üblich die Funktionen in dieser neuen Klassen public static zu machen oder?
Dass man, wie auch schon erwähnt wurde, keine Objekte braucht...

Static macht Sinn, wenn die Methode so aussehen könnte:

myClass.addNode(Tree t, Node n)

Vorausgesetzt, myClass braucht Wissen nicht dauerhaft speichern und benötigt zum Ausführen seiner Aufgabe nur die über t und n verfügbaren Daten, dann kannst Du das static machen.

Fang aber nicht an Static Fields einzusetzen.
Wenn Du einen statischen Wert in irgendeinem instantiierten Objekt veränderst, dann veränderst Du ihn für alle Objekte dieser Klasse.
Static-Variablen und Methoden sind nicht mehr an Objekte, sondern nur noch an die Klasse gebunden.

EDIT:
Mir fällt gerade ein wunderbares Beispiel für Static-Fields ein.
Konstanten! Denn nichts anderes sollte in solchen Variablen gespeichert werden.
Beispielsweise könnte Deine Konstante so aussehen:

public static int ADD_AND_TRAVERSE = 1;

Dann könnte die addNode - Methode z.B. auch so aussehen:
addNode(Tree t, Node n, int Mode) -> aufgerufen dann so:
myClass.addNode(t, n, myClass.ADD_AND_TRAVERSE);

Du könntest dann in dieser Methode auf die Konsante näher eingehen, z.B. so:

if(mode == ADD_AND_TRAVERSE)
{
   //hier wird der Baum nach dem Hinzufügen des Knoten traversiert...
}

 

[Frank123134]

Super, dann ist jetzt alles klar...
Danke nochmal und noch ein schönes Wochenende

 

[mvitz]

So einen Modus, sollte man dann aber lieber über enums regeln, anstatt über int Konstanten.

 

[Sekundentakt]

So einen Modus, sollte man dann aber lieber über enums regeln, anstatt über int Konstanten.

Bisher lief das in allen Projekten die ich gesehen habe über Konstanten.
Gibt es da bei Enums einen besonderen Vorteil?

 

[slawaweis]

große Klassen kommen schon mal vor, bei der Arbeit mit Swing sogar öfters. JTree hat z.B. ~4800 LOC, JTable ~7800 LOC, wobei ~2/3 Dokumentation ist. So kommt es immer auf die Funktionalität an, die benötigt wird. Wenn also eine Klasse per Definition viele Methoden haben muss, muss die Klasse diese auch haben. Folgend ein paar Vorgehensweisen zu möglichen Klassenorganisation.

1. Man kann größere Klassen strukturieren/formatieren. Ich verwende z.B. so ein System:

/////////////////////////////////////////////////////////////////////////////
// Teil 2: Getter / Setter

 public void set...

// Teil 2: Getter / Setter
/////////////////////////////////////////////////////////////////////////////

/////////////////////////////////////////////////////////////////////////////
// Teil 3: Actions

wobei ich eine größere Datei in logische Blöcke unterteile und Oben in der Datei aufschreibe, was es alles für Blöcke gibt.

2. Klassen kann man auch als erweiterten Namespace-Mechanismus verwenden. D.h. eine große Klasse enthält wenig eigener Funktionalität, aber viele innere statische Klassen und bildet eine Art erweitertes Package. Per Refactoring kann man jederzeit diese rausnehmen oder einfügen.

3. Eine weitere Möglichkeit wäre die Delegation. D.h. die Funktionalität wird in einer anderen Klasse implementiert und von dieser Klasse wird in der Hauptklasse eine Instanz erzeugt. Die Methodenaufrufe werden dann von der Hauptklasse in die andere Klasse durchgeschleift. Dazu kann man sich das Delegations-Pattern ansehen.

Delegation pattern - Wikipedia, the free encyclopedia

4. Noch eine Möglichkeit größere Klassen zu verkleinern ist die Auslagerung bestimmter Funktionalität in statische Funktionen in anderen Klassen. Dabei werden der statischen Funktion die benötigten Klassenvariablen übergeben oder zu Not das ganze Objekt. z.B.:

public class Hauptklasse
{
 protected Integer value1 = new Integer(1);
 protected Integer value2 = new Integer(2);

 public Integer operationX(Integer p1, Integer p2)
  {
  return HauptklasseHelper.operationX(value1, value2, p1, p2);
  }

 public Integer operationY(Integer p1, Integer p2)
  {
  return HauptklasseHelper.operationY(this, p1, p2);
  }
}

protected class HauptklasseHelper
{
 protected static Integer operationX(Integer v1, Integer v2, Integer p1, Integer p2)
  {
  return ...
  }

 protected static Integer operationY(Hauptklasse hk, Integer p1, Integer p2)
  {
  return ...
  }
}

allerdings finde ich diese Möglichkeit am hässlichsten, dann lieber größere Klassen.

Slawa

 

[mvitz]

Bisher lief das in allen Projekten die ich gesehen habe über Konstanten.
Gibt es da bei Enums einen besonderen Vorteil?

Evtl. waren das Projekte, die vor Java 1.5 entstanden sind und ja, enums haben Vorteile

1) Ein enum kann noch eigene Methoden haben
2) Ein enum sichert dir Typsicherheit zu. Bei der Methode mit dem Modi, kann man als Aufrufer ja auch einen int übergeben, der zu keinem Modi passt, mit einem enum kann dies nicht passieren.
3) Enums sind halt genau für solche Fälle konzipiert worden, da sollte man diese auch verwenden.

 

[Landei]

4) Enums sind wesentlich unproblematischer, wenn neue Optionen hinzukommen oder alte wegfallen
5) Enums lassen sich leicht in normale Klassen umstrukturieren, wenn man mehr Funktionalität/Flexibilität braucht als ursprünglich geplant

 

[bygones]

Ja, Baum und Knoten sind schon 2 Klassen...
Also,was man noch machen könnte ist die ganzen Queries auslagere.

Also, daß ich dann sowas in der Art:

public class Tree{
...
}

public class Query{

public static Point NearestNeighborSearch(Tree t, Point p){
....
}


public static LinkedList<Point> RangeSearch(Tree t, Range r){
.....
}
}




Dann kann ich z.B. wenn ich nen Tree t und Point o hab mit Query.NearestNeighborSearch(t, p) die NearestNeighbor-abfrage aufrufen....
Ich denk des mach Sinn..
Vielen Dank!

schau dir mal das Visitor Pattern an...