Comment puis-je identifier les objets immuables en Java

Il n'y a aucun moyen fiable de détecter si une classe est immuable. C'est parce qu'il y a de nombreuses façons d'une propriété d'une classe peut être modifié et vous ne pouvez pas détecter tous les d'eux par le biais de la réflexion.

Le seul moyen de se rapprocher de ce qui est:

• Autoriser uniquement les propriétés finales de types qui sont immuables (les types primitifs et les classes que vous connaissez sont immuables),
• Exiger la classe finale
• Exiger qu'ils héritent d'une classe de base que vous fournissez (qui est garanti pour être immuable)

Ensuite, vous pouvez vérifier avec le code suivant si l'objet que vous avez est immuable:

static boolean isImmutable(Object obj) {
    Class<?> objClass = obj.getClass();

    //Class of the object must be a direct child class of the required class
    Class<?> superClass = objClass.getSuperclass();
    if (!Immutable.class.equals(superClass)) {
        return false;
    }

    //Class must be final
    if (!Modifier.isFinal(objClass.getModifiers())) {
        return false;
    }

    //Check all fields defined in the class for type and if they are final
    Field[] objFields = objClass.getDeclaredFields();
    for (int i = 0; i < objFields.length; i++) {
        if (!Modifier.isFinal(objFields[i].getModifiers())
                || !isValidFieldType(objFields[i].getType())) {
            return false;
        }
    }

    //Lets hope we didn't forget something
    return true;
}

static boolean isValidFieldType(Class<?> type) {
    //Check for all allowed property types...
    return type.isPrimitive() || String.class.equals(type);
}

Mise à jour: Comme suggéré dans les commentaires, il pourrait être étendu à recurse sur la super-classe au lieu de vérifier, pour une certaine classe. Il a également été suggéré d'utiliser de manière récursive isImmutable dans le isValidFieldType Méthode. Cela pourrait probablement travailler et j'ai aussi fait quelques tests. Mais ce n'est pas anodin. Vous ne pouvez pas il suffit de cocher tous les types de champ avec un appel à isImmutable, car les chaînes de caractères déjà échoue à ce test (son champ hash n'est pas définitif!). Aussi, vous êtes facilement en cours d'exécution dans d'interminables récurrences, provoquant StackOverflowErrors 😉 d'Autres problèmes peuvent être causés par des médicaments génériques, où vous devez également vérifier leurs types pour immutablity.

Je pense qu'avec un peu de travail, le potentiel de ces problèmes peuvent être résolus en quelque sorte. Mais alors, vous devez vous demander d'abord si elle vaut vraiment la peine (c'est aussi la performance sage).

Dans mon entreprise nous avons défini un Attribut appelé @Immutable. Si vous choisissez de vous joindre à une classe, cela signifie que vous promettons que vous êtes immuable.

Il travaille pour la documentation, et dans votre cas, il fonctionne comme un filtre.

Bien sûr, vous êtes toujours selon l'auteur de garder sa parole au sujet d'être immuable, mais puisque l'auteur a ajouté l'annotation, il est une hypothèse raisonnable.

Cela pourrait être un autre indice:

Si la classe n'a pas de poseurs alors il ne peut pas être muté, accordé paramètres, il a été créé avec sont soit des "primitifs" types ou non mutable eux-mêmes.

Aussi pas de méthodes pourraient être surchargée, tous les champs sont finales et privé,

Je vais essayer de coder quelque chose demain pour vous, mais Simon du code à l'aide de la réflexion semble assez bon.

Dans le temps, essayez de récupérer une copie de la "Effective Java" livre par Josh Bloc , il a un Article relatif à ce sujet. Tout est de ne pas vous dire comment détecter un inmmutable classe, il montre comment créer un bon.

L'élément est appelé: "Favoriser l'immutabilité"

lien:
http://java.sun.com/docs/books/effective/

Vous Pouvez Demander à vos clients d'ajouter des métadonnées (annotations) et de les vérifier au moment de l'exécution, de réflexion, comme ceci:

Métadonnées:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.CLASS)
public @interface Immutable{ }

Code Client:

@Immutable
public class ImmutableRectangle {
    private final int width;
    private final int height;
    public ImmutableRectangle(int width, int height) {
        this.width = width;
        this.height = height;
    }
    public int getWidth() { return width; }
    public int getHeight() { return height; }
}

Puis par l'aide de la réflexion sur la classe, vérifier si elle a l'annotation (je voudrais coller le code, mais son passe-partout et peuvent être trouvés facilement en ligne)

Vous pouvez utiliser des AOP et @Immuable d'annotation à partir d' jcabi-aspects:

@Immutable
public class Foo {
  private String data;
}
//this line will throw a runtime exception since class Foo
//is actually mutable, despite the annotation
Object object = new Foo();

Essayez ceci:

public static boolean isImmutable(Object object){
    if (object instanceof Number) { //Numbers are immutable
        if (object instanceof AtomicInteger) {
            //AtomicIntegers are mutable
        } else if (object instanceof AtomicLong) {
            //AtomLongs are mutable
        } else {
            return true;
        }
    } else if (object instanceof String) {  //Strings are immutable
        return true;
    } else if (object instanceof Character) {   //Characters are immutable
        return true;
    } else if (object instanceof Class) { //Classes are immutable
        return true;
    }

    Class<?> objClass = object.getClass();

    //Class must be final
    if (!Modifier.isFinal(objClass.getModifiers())) {
            return false;
    }

    //Check all fields defined in the class for type and if they are final
    Field[] objFields = objClass.getDeclaredFields();
    for (int i = 0; i < objFields.length; i++) {
            if (!Modifier.isFinal(objFields[i].getModifiers())
                            || !isImmutable(objFields[i].getType())) {
                    return false;
            }
    }

    //Lets hope we didn't forget something
    return true;
}

Découvrez joe-e, une mise en œuvre de capacités pour java.

J'apprécie et j'admire la quantité de travail Grundlefleck a mis dans sa mutabilité détecteur, mais je pense que c'est un peu exagéré. Vous pouvez écrire un simple, mais en pratique très adéquate (c'est pragmatique) détecteur comme suit:

(note: ceci est une copie de mon commentaire ici: https://stackoverflow.com/a/28111150/773113)

Tout d'abord, vous n'allez pas être juste écrire une méthode qui détermine si une classe est immuable; au lieu de cela, vous aurez besoin d'écrire une immutabilité détecteur de classe, parce qu'il va avoir à maintenir un certain état. L'état du détecteur seront détectés immutabilité de toutes les classes dont il a examiné jusqu'à présent. Ce n'est pas seulement utile pour les performances, mais il est en fait nécessaire, car une classe peut contenir une référence circulaire, qui serait la cause d'une simpliste immutabilité détecteur de tomber dans une récursion infinie.

L'immutabilité d'une classe a quatre valeurs possibles: Unknown, Mutable, Immutable, et Calculating. Vous aurez probablement envie d'avoir une carte qui associe à chaque classe que vous avez rencontrés jusqu'à présent à l'immutabilité de la valeur. Bien sûr, Unknown n'a pas réellement besoin d'être mis en œuvre, puisqu'il sera l'état implicite de toute catégorie qui n'est pas encore à la carte.

Ainsi, lorsque vous commencez à l'examen d'une classe, vous l'associez à un Calculating valeur dans la carte, et lorsque vous avez terminé, vous remplacez Calculating soit avec Immutable ou Mutable.

Pour chaque classe, vous avez uniquement besoin de vérifier le champ de membres, pas le code. L'idée de la vérification de bytecode est plutôt mal venu.

Tout d'abord, vous devez pas vérifier si une classe est définitive, La finalité d'une classe n'a pas d'incidence sur son immuabilité. Au lieu de cela, une méthode qui attend un immuable paramètre doit tout d'abord invoquer l'immutabilité détecteur d'affirmer l'immutabilité de la classe de l'objet réel, qui a été adoptée. Ce test peut être omis si le type du paramètre est une classe finale, de sorte que la finalité est bon pour les performances, mais pas strictement nécessaire. Aussi, comme vous le verrez plus bas, un champ dont le type est d'un non-classe finale sera la cause de la classe de déclaration, pour être considéré comme mutables, mais encore, c'est un problème de la classe de déclaration, pas le problème de la non-final immuable membre de la classe. Il est parfaitement acceptable d'avoir une haute hiérarchie de l'immuable classes, dans lequel tous les nœuds non feuille doit bien sûr être non-final.

Vous devriez pas vérifier si un champ est privé; il est parfaitement bien pour une classe à avoir un champ public, et la visibilité du champ n'a pas d'incidence sur l'immutabilité de la classe de déclaration, en aucune manière, la forme ou la forme. Vous avez uniquement besoin de vérifier si le champ est définitive et son type est immuable.

Lors de l'examen d'une classe, ce que vous voulez faire tout d'abord, de manière récursive pour déterminer l'immutabilité de sa super classe. Si le super est mutable, puis le descendant est par définition mutable trop.

Ensuite, vous avez uniquement besoin de vérifier la déclaré champs de la classe, pas tous champs.

Si un champ n'est pas final, votre classe est mutable.

Si un champ est définitif, mais le type du champ est mutable, votre classe est mutable. (Les tableaux sont, par définition, mutable.)

Si un champ est définitive, et le type du champ est Calculating, puis de les ignorer et de passer à la zone suivante. Si tous les champs sont immuables ou Calculating, votre classe est immuable.

Si le type du champ est une interface ou une classe abstraite, ou un non-finale de la classe, alors il est considéré comme mutables, puisque vous n'avez absolument aucun contrôle sur ce que la mise en œuvre effective peut faire. Cela peut sembler comme un problème insurmontable, car cela signifie que l'enveloppant d'un modifiable collection à l'intérieur d'un UnmodifiableCollection échouera toujours l'immutabilité de test, mais il est en fait très bien, et il peut être manipulé avec la solution de contournement suivante.

Certaines classes peuvent contenir des non-final champs et encore efficacement immuable. Un exemple de ceci est le String classe. D'autres classes qui entrent dans cette catégorie sont des classes qui contiennent des non-finale membres purement à des fins de contrôle des performances (invocation des comptoirs, etc.), les classes qui implémentent de popsicle immutabilité (regarder), et des classes qui contiennent des membres qui sont des interfaces qui sont connus pour ne pas causer des effets secondaires. Aussi, si une classe contient de véritables champs mutables, mais il promet de ne pas les prendre en compte lors du calcul de hashCode() et equals(), puis la classe est bien sûr dangereux quand il s'agit de multi-threading, mais il peut encore être considérée comme immuable pour le but de l'utiliser comme une clé dans une carte. Donc, tous ces cas peuvent être traités de deux façons:

1. D'ajouter manuellement les classes et interfaces) pour votre immutabilité du détecteur. Si vous savez qu'une certaine classe est effectivement immuable malgré le fait que l'immutabilité de test pour qu'il échoue, vous pouvez manuellement ajouter une entrée à votre détecteur qui associe avec Immutable. De cette façon, le détecteur ne tentera jamais de vérifier si elle est immuable, il sera toujours juste de dire " oui, il est.'

2. L'introduction d'un @ImmutabilityOverride annotation. Votre immutabilité détecteur permet de vérifier la présence de cette annotation sur un champ, et s'il est présent, il peut considérer le champ comme immuable, malgré le fait que le champ peut être non-final ou son type peut être mutables. Le détecteur peut également vérifier la présence de cette annotation sur la classe, donc le traitement de la classe comme immuable, sans même prendre la peine de vérifier ses champs.

J'espère que cela aide les générations futures.