Was ist die beste Vorgehensweise zum Erstellen stateless Utility-Klassen in Java?

Wenn Sie meine Metapher für ein bisschen verwöhnen ...

Sie haben wahrscheinlich schon eine davon gesehen:

Beachten Sie, dass wir es einen Toaster nennen. Wir nennen nicht es ein "BreadUtil".

Ähnlich können utility-Methoden in einer Klasse platziert werden, die nach einer bestimmten Funktionalität benannt ist, und nicht "verschiedene Dinge, die mit Brot zu tun haben."

Die meisten statischen Methoden gehören zu einer verwandten Klasse. zum Beispiel Integer.parseInt ist eine statische Methode der Integer-Klasse und kein Mitglied einer theoretischen IntegerUtil- oder NumberUtil-Klasse.

In der Vergangenheit war ein Fall für das Erstellen einer separaten Dienstprogrammklasse, wenn die primäre Klasse von Interesse eine Schnittstelle war. Ein Beispiel dafür ist java.util.Collections . Ab Java 8 ist dies jedoch keine Entschuldigung, da Schnittstellen statische Methoden und Standardmethoden haben können. Tatsächlich wurde Collections.sort (List) bereits nach List.sort .

Wenn Sie viele Hilfsmethoden haben und der Meinung sind, dass sie die relevante Klasse durcheinander bringen würden, ist es in Ordnung, sie in eine separate Klasse zu stellen, aber nicht in eine "BreadUtil" -Klasse. Es ist niemals akzeptabel, das Wort "util" in einen Klassennamen (oder "utils", "utilities", "misc", "sonstiges", "general", "shared", "common" oder "framework") einzufügen. . Geben Sie der Klasse einen aussagekräftigen Namen, der beschreibt, wozu die Methoden dienen. Wenn die Methoden zu verschieden sind, um einen solchen Klassennamen zuzulassen, müssen Sie sie wahrscheinlich in mehrere Klassen aufteilen. (Kleine Klassen mit nur wenigen Methoden sind durchaus akzeptabel; viele Leute halten das sogar für ein gutes Design.)

Wenn Sie zu dem Integer-Beispiel zurückkehren, wenn Sie der Meinung sind, dass die Methoden die Klasse überladen, können Sie neue Klassen wie folgt erstellen:

Der letzte von diesen ist ein Beispiel für etwas, das ohne statische Methoden besser sein könnte:

Ich denke, die gebräuchlichste Methode besteht darin, statische Methoden zu erstellen. Als Beispiel siehe StringUtils in Apache Commons Lang , Streicher in Guava oder sogar Arrays in JDK .

Auch sollte die Klasse endgültig sein und sie sollte einen privaten Konstruktor haben, um zu vermeiden, dass sie erbt oder instantiiert.

Entweder Sie verwenden statische Methoden oder ein Singleton, es sollte die gleiche Anstrengung sein, es zu testen. Im letzteren Fall könnten Sie etwas mehr Code (Zeichen) schreiben.

Ich weiß, dass OO-Puristen die Existenz solcher Klassen streiten werden, und ich werde dazu neigen, ihnen zuzustimmen, aber diese werden nur der Einfachheit halber hinzugefügt, und Sie sollten die Anzahl solcher Klassen begrenzen.

  

Was ist die beste Vorgehensweise zum Erstellen der Utility-Klassen (die keinen Status enthalten) in Java.

Meiner Meinung nach ist der beste Weg, Hilfsklassen wann immer möglich wegzulassen.

Eine Dienstprogrammklasse kehrt die Idee der objektorientierten Programmierung um. Wenn Sie zu dem Punkt kommen, an dem Sie eine neue Methode benötigen, fügen Sie sie normalerweise der Klasse mit der höchsten Kohäsion hinzu. Dies bedeutet für die Klasse, die die meisten Informationen enthält, die die Methode benötigt. Die anderen Informationen werden als Parameter in die Methode übernommen. Wenn die Parameterliste zu lang wird, ist dies oft ein Indikator für eine falsch platzierte Methode.

Es gibt seltene Situationen, in denen Sie wirklich eine Dienstprogrammklasse benötigen, um eine Methode für einen bestimmten Typ bereitzustellen. Z.B.

• Wenn Sie die Methode nicht zum Quellcode hinzufügen können, weil Sie sie nicht besitzen (aber Sie könnten entweder einen Wrapper erstellen oder eine Unterklasse erstellen)
• wenn eine Klasse, die die zusätzliche Methode benötigt, endgültig ist und Sie den Quellcode nicht besitzen (z. B. StringUtility)

  

In den meisten Fällen erstellen wir statische Methoden für solche Aufgaben. Ein anderer möglicher Weg könnte sein, "die Singleton-Objekte zu erzeugen", um diese Operation durchzuführen.

     

Was sollte die Designüberlegung sein, wenn die Anforderung der Code leicht Unit-testbar sein sollte?

Wenn Sie Utility-Klassen aus einer Unit-Testbarkeits-Perspektive betrachten und die Utility-Klasse vortäuschen wollen, sollten Sie das Singleton verwenden, da Objektreferenzen ersetzt werden können.

Entweder durch Ändern der Singleton-Instanzreferenz (die statische Variable) oder auf der Clientseite mithilfe eines Objektfelds. ZB

Statische Methodenaufrufe sind schwer zu ersetzen. Einige Test-Frameworks wie powermock unterstützen Mocking von statischen Aufrufen , indem sie den Client-Bytecode neu schreiben. Aber ich denke, dass diese Frameworks entwickelt wurden, um Unit-Testing von schlechtem Legacy-Code zu unterstützen. Wenn Sie powermock für neuen Code benötigen, sollten Sie Ihr Design überdenken.