Sollten Helper/Utility-Klassen abstrakt sein?

Question

Ich ertappe mich häufig dabei, dass ich allgemeines Verhalten aus Klassen in Hilfs- bzw. Dienstleistungsklassen extrahiere, die nichts anderes als eine Reihe statischer Methoden enthalten. Ich habe mich oft gefragt, ob ich diese Klassen als abstrakt deklarieren sollte, da mir kein triftiger Grund einfällt, sie jemals zu instanziieren?

Was wären die Vor- und Nachteile, wenn eine solche Klasse als abstrakt deklariert würde?

public [abstract] class Utilities{

   public static String getSomeData(){
       return "someData";
   }

   public static void doSomethingToObject(Object arg0){
   }
}

Answer 1

Wie bereits erwähnt, sollten Sie einen privaten Konstruktor ohne Parameter erstellen. Niemand kann eine Instanz davon erstellen, außer der Klasse selbst.

Da andere gezeigt haben, wie es mit anderen Sprachen gemacht wird, kommt hier, wie man es in der nächsten C++-Version macht, wie man eine Klasse nicht-instantiabel macht:

struct Utility { 
    static void doSomething() { /* ... */ } 
    Utility() = delete; 
};

Answer 2

Ich denke, es ist besser, Utility-Klassen mit einem privaten Konstruktor ohne Args als final zu deklarieren. Außerdem sollten alle Mitglieder dieser Klasse statisch sein.

Eine einfache Möglichkeit, all dies in einer einzigen Anweisung zu tun, ist die Verwendung der @UtilityClass Anmerkung zu Lombok :

@UtilityClass
public class Utilities{

   public String getSomeData() {
       return "someData";
   }

   public void doSomethingToObject(Object arg0) {
   }
}

Wenn Sie die @UtilityClass Annotation können Sie die statischen Schlüsselwörter wie im obigen Beispiel weglassen, da Lombok sie während der Kompilierung automatisch hinzufügt.

Answer 3

Nein, aber wenn Ihre Sprache es unterstützt, spricht vieles dafür, dass sie in den meisten Fällen als "statisch" deklariert werden sollten (können)... Static teilt dem Compiler mit, dass sie nicht instanziiert werden können und dass alle Methoden in ihnen statisch sein müssen.

Abstrakt ist für Klassen, die über instanzbasierte Implementierungsdetails verfügen, die von Instanzen abgeleiteter Klassen verwendet werden sollen...

Answer 4

Helper / Utility Methoden sind in Ordnung. Machen Sie sich keine Gedanken über das Hinzufügen zu einer Bibliothek innerhalb Ihrer Anwendung oder Ihres Frameworks. Die meisten Frameworks, die ich gesehen habe, verwenden sie in vielen Varianten.

Wenn Sie sich allerdings richtig schlau machen wollen, sollten Sie sich mit folgenden Themen beschäftigen Erweiterungsmethoden in C# 3.0. Durch die Verwendung von Erweiterungsmethoden werden Ihre Dienstprogramme ein wenig mehr zu einem "ganzheitlichen" Teil Ihres Frameworks, was Sie anscheinend anstreben, indem Sie sie abstrakt machen wollen. Ganz zu schweigen davon, dass es viel Spaß macht, Erweiterungsmethoden zu schreiben!

Answer 5

Jemand erwähnte, dass man dies in C# 3.0 über Erweiterungsmethoden erreichen kann. Ich bin nicht ein C# Kerl, tat einige zurück in der 1.5/2.0 Tage, aber nicht verwendet haben, es seitdem. Basierend auf einem sehr flüchtigen Verständnis denke ich, etwas ähnliches kann in Java mit statischen Importen erreicht werden. Mir ist klar, dass das nicht ganz dasselbe ist, aber wenn das Ziel darin besteht, diese Utility-Methoden für die aufrufende Klasse ein wenig "nativer" (in Ermangelung eines besseren Begriffs) erscheinen zu lassen, denke ich, dass es den Zweck erfüllen wird. Angenommen, die Utilities-Klasse, die ich in meiner ursprünglichen Frage angegeben habe.

import static Utilities.getSomeData;

public class Consumer {

    public void doSomething(){

        String data =  getSomeData();
    }

}