Kapselung Statische Helper Klassen

[Sanix]

Ich bin in letzter Zeit häufiger auf riese Helperklassen gestossen, die 1000 Zeilen gross sind und andere Helperklassen callen. Sämtliche Methoden sind statisch, was nicht so verkehrt ist, da sie keinen State brauchen.
Jetzt ist das Problem, dass wenn man testen will, auf die Schnauze fliegt. Es ist schwer mockbar und man kriegt es auch nicht wirklich getrennt. Macht man das Ganze nicht statisch führt das zu solchem Code:

new UserCreationHelper().createUser(....)

Wie handhabt ihr das in der Regel? Ich habe bisschen gegoogled und es gibt solche, die aus Prinzip keine statischen Methoden mehr schreiben.

 

[Java Umsteiger]

Ich mach das immer so, dass ich die Methoden der Helper-Klasse importiere:

...
import static Helper.*;
...

dann braucht man die Klasse nicht dazu schreiben oder neu erstellen.

 

[kaetzacoatl]

Constructor private machen.
Dann gibts nur noch denn
direkten Aufruf.

 

[SlaterB]

die ersten beiden Antworten sind wohl nicht ganz beim Thema, static fällt weg,
für das normale Objekt ist 'new UserCreationHelper().createUser(....)' als zu lange Schreibweise in Frage gestellt

grundsätzlich kann so ein Code da gar nicht stehen, der wäre ja genausowenig variabel/ testbar wie ein statischer Aufruf,
jedenfalls nicht wenn an zig Codestellen auf diese Weise und wenn nicht in UserCreationHelper noch eine Indirektion/ eine Unterscheidung stattfindet

besser für Austauschbarkeit und auch etwas schreibärmer ist eine interne Konfiguration, der Helper ist im Objekt bereits gesetzt,
dann getUserHelper().createUser(..);
für besonders häufige Fälle auch direkt eine Methode createUser(..), die intern an getUserHelper() weiterleitet

hat man nur wenige Helper, dann kürzer zu benennen denkbar, bis hin zu getHelper(),
gibt es mehrere Helper, könnten die ineinander konfiguriert sein:
getHelper().getUserHelper().createUser(..);
wiederum bei häufigen Gebrauch eines Unter-Helpers eine eigene Methode dafür, zurück zu
getUserHelper().createUser(..);
wobei getUserHelper() den UserHelper aus getHelper() holt

heute schon das Wort Helper erwähnt? sicherlich allgemein auch verpöhnt, ich persönlich nutze auch 'Context'

worauf ich jedenfalls in den letzten Zeilen hinauswollte ist, dass jene normale Klasse genau ein Attribut mit Link auf zentralen Helper/ Context benötigt, besser als viele Einzelattribute,
der Helper kann ziemlich am Anfang einmal erstellt und initial verteilt werden,
danach im Hintergrund oder offensichtlicher im Konstruktor an weitere Programmklassen, überall verfügbar

das wäre dann natürlich ein ziemlich zentrales Programmelement, nix für jede neue kleine Einführung,
die Zentralität ermöglicht aber gerade erst die gute Austauschbarkeit

Dependency Injection ? Wikipedia
ist dazu sicher auch ein Thema

 

[nillehammer]

Wie handhabt ihr das in der Regel? Ich habe bisschen gegoogled und es gibt solche, die aus Prinzip keine statischen Methoden mehr schreiben.

// Zunächst public Interface definieren
public interface Helper {
  // die ganzen Methoden definieren
}

// Dann package-visible enum mit genau einem Element
enum HelperImpl implements Helper{
  INSTANCE;
  // die ganzen Methoden aus dem Interface implementieren
}

// Dann Facade für Zugriff auf Implementierung
public class HelperFacade {

  public static Helper getHelper() {
   return HelperImpl.INSTANCE;
  }
}

So mach ich es. Man könnte auch die Facade als Interface mit Implementierung gestalten, um ganz ohne public static Methoden auszukommen, aber das finde ich dann doch etwas überkandidelt.

 

[Sanix]

Vielen Dank für die letzten 2 Antworten. Die ersten 2 gingen wohl wirklich am Thema vorbei.

So werden wir das wohl auch lösen müssen. Irgendwie habe ich das Gefühl, das mit J2EE wieder viel prozedural programmiert wird, was eigentlich Helperklassen genau sind.

Das ganze über Dependency Injection ist ja eigentlich nichts anderes als der oben beschriebene Ansatz, einfach das die Factory vom Container übernommen wird.