API Java collections: pourquoi les classes non modifiables[List|Set|Map] ne sont-elles pas visibles publiquement?

Personnellement, je suis entièrement d'accord avec vous. Au cœur du problème est le fait que les génériques de Java ne sont pas covariants, ce qui, à son tour, est dû au fait que les collections de Java sont mutables.

, Il n'est pas possible pour Java du type de système de codifier un type qui semble avoir mutateurs est réalité immuable. Imaginez si nous devions commencer à concevoir une solution:

interface Immutable //marker for immutability

interface ImmutableMap<K, V> extends Map<K, V>, Immutable

, Mais alors ImmutableMap est une sous-classe de Map, et donc Map est assignable à partir de ImmutableMap de sorte que toute méthode qui renvoie une telle carte immuable:

public ImmutableMap<K, V> foo();

Peut être affecté à une carte et peut donc être muté au moment de la compilation:

Map<K, V> m = foo();
m.put(k, v); //oh dear

Donc, vous pouvez voir que l'ajout de ce type ne nous a pas empêché de faire quelque chose de mal. Je pense que pour cette raison, on a jugé qu'il n'avait pas assez à offrir.

Un langage comme scala a des annotations de variance de site de déclaration. Autrement dit, vous pouvez spécifier un type comme étant covariant (et par conséquent immuable) comme l'est la carte de Scala (en fait, elle est covariante dans son paramètre V). Par conséquent, votre API peut déclarer si son type de retour est mutable ou immuable.

Par ailleurs, Scala vous permet de déclarer les types d'intersection afin que vous n'ayez même pas besoin de créer l'interface ImmutableXYZ en tant qu'entité distincte, vous pouvez spécifier une méthode pour retourner:

def foo : XYZ with Immutable

Mais alors scala a un système de type approprié, alors que Java ne le fait pas

S'il est important pour vous de vérifier si la liste a été créée avec des Collections.unmodifiableList alors vous pouvez créer une instance et demander la classe. Maintenant, vous vous pouvez comparer cette classe avec la classe de toute liste.

private static Class UNMODIFIABLE_LIST_CLASS = 
    Collections.unmodifiableList( new ArrayList() ).getClass();
...
if( UNMODIFIABLE_LIST_CLASS == listToTest.getClass() ){
    ...
} 

La réponse au pourquoi est assez simple: à l'époque, en 1998, le design efficace était un peu flanqué. Les gens y pensaient, ce n'était apparemment pas une priorité. Mais il n'y avait pas de vraie réflexion profonde à ce sujet.

Si vous souhaitez utiliser un tel mécanisme, utilisez ImmutableList/Set/Map/de Guava...

Ils sont explicitement immuables et une bonne pratique lors de l'utilisation de cette bibliothèque n'est pas de renvoyer une liste par exemple mais une ImmutableList. Donc, vous saurez qu'une liste / Set / Map/... être immuable.

Exemple:

private final ImmutableList constants = ...;
public final ImmutableList<String> getConstants() {
  return constants;
}

A propos de la conception elle-même de UnmodifiableXxx, on aurait pu faire ce qui suit:

public static final class UnmodifiableXxx implements Xxx { // don't allow extend
  // static if inside Collections
  UnmodifiableXxx (Xxx backend) { // don't allow direct instanciation
    ...
  }
  ...
}

• possibilité d'indiquer une valeur de retour plus spécifique (telle que UnmodifiableList), afin qu'un utilisateur de l'API ne vienne pas à l'idée de modifier cette collection;

Dans une API appropriée, cela devrait déjà être documenté dans le javadoc de la méthode renvoyant la liste non modifiable.

• capacité à vérifier lors de l'exécution si un List est instanceof UnmodifiableList.

Un tel besoin indique que le problème réel se trouve ailleurs. C'est une faille dans la conception du code. Demandez-vous, avez-vous déjà avait la nécessité de vérifier si un List est une instance de ArrayList ou LinkedList? Que ce soit un ArrayList, LinkedList ou UnmodifiableList est clairement une décision qui doit être prise pendant le temps d'écriture du code, pas pendant l'exécution du code. Si vous rencontrez des problèmes parce que vous essayez de modifier un UnmodifiableList (pour lequel le développeur de l'API peut avoir de très bonnes raisons qui devraient être déjà documentées), alors c'est plutôt votre propre faute, pas un défaut d'exécution.

Tous avec tous les, il ne fait aucun sens. Le Collections#unmodifiableXXX(), synchronizedXXX() et checkedXXX() ne représentent en aucune façon des implémentations concrètes. Ils sont tous juste décorateurs qui peut être appliqué indépendamment de la mise en œuvre concrète sous-jacente.

Supposons UnmodifiableList était une classe publique. Je soupçonne que cela bercerait les programmeurs dans un faux sentiment de sécurité. Rappelez-vous, UnmodifiableList est un afficher de modifiable List. Cela signifie que le contenu d'un UnmodifiableList peut toujours changer via les modifications apportées à son List sous-jacent. Un programmeur naïf peut ne pas comprendre cette nuance et peut s'attendre à ce que les instances de UnmodifiableList soient immuables.

Je pense que la réponse est parce que le formulaire de méthode connaît correctement les génériques utilisés et ne nécessite aucune programmation supplémentaire pour transmettre ces informations, tandis que le formulaire de classe nécessiterait plus de déconner. La forme de méthode pour unmodifiableMap a deux arguments génériques flottants, qu'elle mappe à la fois aux arguments génériques du type de retour et de l'argument passé.

public static <K,V> Map<K,V> unmodifiableMap(Map<? extends K, ? extends V> m) {
    return new UnmodifiableMap<K,V>(m);
}