Interfaces avec champs statiques en java pour le partage des "constantes".

Question

Je suis en train de regarder quelques projets Java open source pour me familiariser avec Java et je remarque que beaucoup d'entre eux ont une sorte d'interface de "constantes".

Par exemple, traitement.org possède une interface appelée PConstants.java et la plupart des autres classes principales mettent en œuvre cette interface. L'interface est truffée de membres statiques. Y a-t-il une raison pour cette approche, ou est-ce considéré comme une mauvaise pratique ? Pourquoi ne pas utiliser les enums où cela a du sens ou une classe statique ?

Je trouve étrange d'utiliser une interface pour permettre une sorte de pseudo "variables globales".

public interface PConstants {

  // LOTS OF static fields...

  static public final int SHINE = 31;

  // emissive (by default kept black)
  static public final int ER = 32;
  static public final int EG = 33;
  static public final int EB = 34;

  // has this vertex been lit yet
  static public final int BEEN_LIT = 35;

  static public final int VERTEX_FIELD_COUNT = 36;

  // renderers known to processing.core

  static final String P2D    = "processing.core.PGraphics2D";
  static final String P3D    = "processing.core.PGraphics3D";
  static final String JAVA2D = "processing.core.PGraphicsJava2D";
  static final String OPENGL = "processing.opengl.PGraphicsOpenGL";
  static final String PDF    = "processing.pdf.PGraphicsPDF";
  static final String DXF    = "processing.dxf.RawDXF";

  // platform IDs for PApplet.platform

  static final int OTHER   = 0;
  static final int WINDOWS = 1;
  static final int MACOSX  = 2;
  static final int LINUX   = 3;

  static final String[] platformNames = {
    "other", "windows", "macosx", "linux"
  };

  // and on and on

}

Answer 1

C'est généralement considéré comme une mauvaise pratique. Le problème est que les constantes font partie de l'"interface" publique (faute d'un meilleur terme) de la classe d'implémentation. Cela signifie que la classe d'implémentation publie toutes ces valeurs à des classes externes, même si elles ne sont requises qu'en interne. Les constantes prolifèrent dans tout le code. Un exemple est le SwingConstants dans Swing, qui est mise en œuvre par des dizaines de classes qui "réexportent" toutes l'interface suivante tous de ses constantes (même celles qu'ils n'utilisent pas) comme les leurs.

Mais ne me croyez pas sur parole, Josh Bloch dit aussi c'est mauvais :

Le modèle d'interface constant est une mauvaise utilisation des interfaces. Le fait qu'une classe utilise certaines constantes en interne est un détail d'implémentation. L'implémentation d'une interface de constantes entraîne une fuite de ce détail d'implémentation dans l'API exportée de la classe. Il n'y a aucune conséquence pour les utilisateurs d'une classe que celle-ci implémente une interface constante. En fait, cela peut même les perturber. Pire, cela représente un engagement : si, dans une version ultérieure, la classe est modifiée de telle sorte qu'elle n'a plus besoin d'utiliser les constantes, elle doit quand même implémenter l'interface pour assurer la compatibilité binaire. Si une classe non définitive implémente une interface constante, toutes ses sous-classes verront leurs espaces de noms pollués par les constantes de l'interface.

Un enum peut être une meilleure approche. Ou vous pourriez simplement placer les constantes en tant que champs statiques publics dans une classe qui ne peut pas être instanciée. Cela permet à une autre classe d'y accéder sans polluer sa propre API.

Answer 2

Au lieu de mettre en œuvre une "interface de constantes", en Java 1.5+, vous pouvez utiliser les importations statiques pour importer les constantes/méthodes statiques d'une autre classe/interface :

import static com.kittens.kittenpolisher.KittenConstants.*;

Cela permet d'éviter que vos classes n'implémentent des interfaces qui n'ont aucune fonctionnalité.

Quant à la pratique consistant à avoir une classe uniquement pour stocker les constantes, je pense que c'est parfois nécessaire. Il y a certaines constantes qui n'ont tout simplement pas leur place naturelle dans une classe, il est donc préférable de les avoir dans un endroit "neutre".

Mais au lieu d'utiliser une interface, utilisez une classe finale avec un constructeur privé. (Rendant impossible l'instanciation ou la sous-classification de la classe, envoyant un message fort qu'elle ne contient pas de fonctionnalité/données non statiques).

Eg :

/** Set of constants needed for Kitten Polisher. */
public final class KittenConstants
{
    private KittenConstants() {}

    public static final String KITTEN_SOUND = "meow";
    public static final double KITTEN_CUTENESS_FACTOR = 1;
}

Answer 3

Je ne prétends pas avoir raison, mais voyons ce petit exemple :

public interface CarConstants {

      static final String ENGINE = "mechanical";
      static final String WHEEL  = "round";
      // ...

}

public interface ToyotaCar extends CarConstants //, ICar, ... {
      void produce();
}

public interface FordCar extends CarConstants //, ICar, ... {
      void produce();
}

// and this is implementation #1
public class CamryCar implements ToyotaCar {

      public void produce() {
           System.out.println("the engine is " + ENGINE );
           System.out.println("the wheel is " + WHEEL);
      }
}

// and this is implementation #2
public class MustangCar implements FordCar {

      public void produce() {
           System.out.println("the engine is " + ENGINE );
           System.out.println("the wheel is " + WHEEL);
      }
}

ToyotaCar ne sait rien de FordCar, et FordCar ne sait rien de ToyotaCar. Le principe CarConstants devrait être modifié, mais...

Les constantes ne doivent pas être modifiées, car la roue est ronde et l'égine est mécanique, mais... Dans le futur, les ingénieurs de recherche de Toyota ont inventé le moteur électronique et les roues plates ! Voyons notre nouvelle interface

public interface InnovativeCarConstants {

          static final String ENGINE = "electronic";
          static final String WHEEL  = "flat";
          // ...
}

et maintenant nous pouvons changer notre abstraction :

public interface ToyotaCar extends CarConstants

à

public interface ToyotaCar extends InnovativeCarConstants 

Et maintenant, si nous devons changer la valeur fondamentale du MOTEUR ou de la ROUE, nous pouvons modifier l'interface ToyotaCar au niveau de l'abstraction, sans toucher aux implémentations.

Ce n'est PAS SÛR, je sais, mais je veux quand même savoir ce que vous pensez de ça.

Answer 4

Avec le recul, nous pouvons constater que Java est cassé à bien des égards. L'un des principaux défauts de Java est la restriction des interfaces aux méthodes abstraites et aux champs statiques finaux. Des langages OO plus récents et plus sophistiqués comme Scala subsument les interfaces par des traits qui peuvent inclure (et incluent généralement) des méthodes concrètes, qui peuvent avoir une arité zéro (constantes !). Pour un exposé sur les traits en tant qu'unités de comportement composable, voir http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf . Pour une brève description de la comparaison entre les traits en Scala et les interfaces en Java, voir http://www.codecommit.com/blog/scala/scala-for-java-refugees-part-5 . Dans le contexte de l'enseignement de la conception OO, les règles simplistes telles que l'affirmation selon laquelle les interfaces ne devraient jamais inclure de champs statiques sont stupides. De nombreux traits incluent naturellement des constantes et ces constantes font convenablement partie de l'"interface" publique supportée par le trait. Dans l'écriture du code Java, il n'existe pas de moyen propre et élégant de représenter les traits, mais l'utilisation de champs statiques finaux dans les interfaces fait souvent partie d'une bonne solution de contournement.

Answer 5

Selon les spécifications de la JVM, les champs et les méthodes d'une interface ne peuvent être que Public, Static, Final et Abstract. Réf. de l'intérieur de Java VM

Par défaut, toutes les méthodes de l'interface sont abstraites, même si vous ne l'avez pas mentionné explicitement.

Les interfaces sont censées ne donner que des spécifications. Elles ne peuvent pas contenir d'implémentations. Ainsi, pour éviter que les classes d'implémentation ne modifient la spécification, elle est rendue finale. Puisque les interfaces ne peuvent pas être instanciées, elles sont rendues statiques pour accéder au champ en utilisant le nom de l'interface.