Richtlinien wie man Classen in Packages organisieren soll?

[sirbender]

Hi,

wie man ein grosses Projekt in Einzelteile (Module/jars) aufspaltet sollte jedem einleuchten. Ein Jar fuer Graphics Operationen, ein Jar fuer mathematische Utils, usw.
Die Aufspaltung ergibt sich oft aus dem gesunden Menschenverstand 😉

Wie ist es aber wenn es darum geht Klassen in Packages zu stecken? Manche Leute stecken alles in ein Package, andere wiederum haben viele Packages mit wenigen Klassen, wiederum andere erstellen viele Sub- und Sub-Sub-Packages und die meisten machen ein Mix davon.

Gibt es irgendwelche einleuchtenden Richtlinien oder Tips wie man vorgehen sollte? Ob man Klassen innerhalb eine Packages z.B. moeglichst private macht und eine einzelne Klasse schreibt ueber die indirekt auf alle Klassen des Packages zugegriffen wird, usw.

Irgendwie scheint es mir als wuerde jeder gerade so machen wie er Lust hat ohne gross drueber nachzudenken.

Danke,
sb

 

[c_sidi90]

Hängt meist vom Projekt selbst ab, da sollte man sich für jedes Projekt aufs neue kurz Gedanken machen ,auch wenn es viele Vorgehensweisen gibt die immer gleich ablaufen.

Verschiedene Module, verschiedene Bereiche, verschiedene benötigte Frameworks usw.

Ich sag mir immer, less is more, viele packages sind am Ende auch keine Organisationshilfe wenn sich in jedem Package nur eine Jar befindet 😛

 

[nillehammer]

Sofern man packages nur als Schubladen begreift, damit nicht soiviel auf einmal in einem Ordner steht, kann man sie sich fast schenken. Ich finde sie bekommen Ihren Sinn erst dadurch, dass man mit Sichtbarkeitsmodifizierern bestimmte Methoden oder sogar ganze Klassen verstecken kann. Dadurch bekommt man eine schlanke API (Summe alles dessen, was public ist). Ein Package ist fü mich also mehr ein Rahmen für eine bstimmte Funktionalität.

Beispiel: Du willst einen (zugegeben wenig nutzbringenden) Service implementieren, der eine bestimmte Zeile einer Datei liest. Als guter Programmierer definierst du Dir zunächst ein Interface:

public interface LineReader {
  public String readLineFromfile(int lineNumber, String filePathName);
}

Ohne Implementierung macht das natürlich wenig Sinn. Also schreibst du eine Impl-Klasse. Du willst den Nutzer Deiner API aber zwingen, gegen das Interface zu programmieren. Er darf die Klasse also nicht sehen.

// Klasse hat default-Visibility, kann von außerhalb des package also nicht gesehen werden.
final class LineReaderDefaultImpl implements LineReader{
  // Konstruktor hat auch Default-Visibility.
  LineReader(){};

  @Override
  public final String readLineFromFile(final int lineNumber, final String filePathName) {
   // hier Dein toller Impl-Code
  }
}

Der Nutzer Deiner API kommt jetzt an deine Impl-Klasse nicht ran. Also schreibst Du noch eine Factory:

public final class ServiceFactory {

  public static LineReader createLineReader() {
    return new LineReaderImpl();
  }
}

Auf diese Weise zwingst Du den Nutzer, immer gegen das Interface zu programmieren. Er kann garnicht anders. Wenn Du nun deine Impl-Klasse austauschen möchtest, weil es in Java7 ganz tolle neue Funktionen für Zugriffe auf das Filesystem gibt, kannst Du das einfach machen. Du musst nicht darüber nachdenken, dass ein Nutzer Deine Impl-Klasse benutzt und sein Code nach Deinen Updates möglicherweise nicht mehr läuft.

 

[vanny]

Mir sind keine Richtlinien bekannt (was nicht heisst, dass es die nicht gibt^^).
Ich finde es nützlich, durch packages den "FingerWeg-Code"(zBsp. Factory-Klassen/FrameWorks etc.) vom "HierWirdGewurschtelt-Code" zu trennen.
Gui und interne Logik ist auch sinnvoll.
Alles andere ist dann eher Geschmackssache und hängt vom jew. Fall ab.

Gruß Vanny