Les classes utilitaires / utilitaires doivent-elles être abstraites?

Question

Je me trouve souvent en train d'extraire un comportement commun de classes en classes d'assistance / utilitaire qui ne contiennent rien d'autre qu'un ensemble de méthodes statiques. Je me suis souvent demandé si je devrais déclarer ces classes comme étant abstraites, car je ne peux pas vraiment penser à une raison valable pour les instancier un jour.

Quels seraient les avantages et inconvénients de déclarer une telle classe abstraite?

 public [abstract] class Utilities{

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

   public static void doSomethingToObject(Object arg0){
   }
}
 

Answer 1

Vous pouvez simplement déclarer un constructeur privé qui ne fait rien.

Le problème avec la déclaration "abstraite" de la classe est que le mot clé abstract signifie généralement que la classe est destinée à être sous-classée et étendue. Ce n'est certainement pas ce que vous voulez ici.

Answer 2

Ne prenez pas la peine de les rendre abstraites, mais incluez un constructeur privé sans paramètre pour les empêcher d’être instanciées.

Point de comparaison pour les personnes intéressées: en C #, vous déclareriez la classe statique, ce qui la rend abstraite et scellée (la version finale de Java) dans la forme compilée, sans aucun constructeur d'instance. Cela rend également une erreur de compilation lors de la déclaration d'un paramètre, d'une variable, d'un tableau, etc. de ce type. Pratique.

Answer 3

Je ne déclare pas les classes d’utilité abstraites, je les déclare comme final et rend le constructeur privé. De cette façon, ils ne peuvent pas être sous-classés et ils ne peuvent pas être instanciés.

 

public final class Utility
{
    private Utility(){}

    public static void doSomethingUseful()
    {
        ...
    }
}
 

Answer 4

Je voudrais ajouter plus loin que le constructeur privé:

public class Foo {
   // non-instantiable class
   private Foo() { throw new AssertionError(); }
}

Jeter l'erreur d'assertion permet de créer des méthodes de la même classe, à partir de l'instanciation de la classe (enfin, il essaie). Ce n'est normalement pas un problème, mais dans un environnement d'équipe, vous ne savez jamais ce que quelqu'un le fera.

En ce qui concerne le "résumé" mot-clé, j'ai remarqué que les classes utilitaires sous-classé dans de nombreux cas:

public class CoreUtils { ... }
public class WebUtils extends CoreUtils { ... }

public class Foo { ... WebUtils.someMethodInCoreUtils() ... }

Je crois que c'est fait pour que les gens n'ont pas à se rappeler qui classe utilitaire pour inclure. Existe-il des inconvénients à cela? Est-ce un anti-modèle?

En ce qui concerne, LES

Answer 5

En les déclarant abstraits, vous indiquez à d’autres codeurs à partir desquels vous souhaitez que ces classes soient dérivées. Vraiment, vous avez raison, il n'y a pas beaucoup de différence, mais la sémantique ici concerne davantage l'interprétation des autres personnes qui consultent votre code.