Pourquoi aurait-on déclarer un immuable classe final en Java?

J'ai lu que pour faire un classe immuable en Java, nous devons faire le suivant,

  1. Ne pas fournir toutes les poseurs de
  2. Marque tous les champs privés
  3. Faire la classe finale

Pourquoi l'étape 3? Pourquoi devrais-je marquer la classe final?

  • java.math.BigInteger classe est de donner l'exemple, c'est les valeurs sont immuables, mais elle n'est pas définitive.
  • Si vous avez un BigInteger, vous ne savez pas si il est immuable ou pas. C'est une foiré conception. / java.io.File est un exemple plus intéressant.
  • Ne pas permettre à des sous-classes pour remplacer les méthodes - la façon La plus simple de le faire est de déclarer la classe comme final. Une approche plus sophistiquée consiste à rendre le constructeur privé et de construire des instances dans l'usine de méthodes de docs.oracle.com/javase/tutorial/essential/concurrency/...
  • pouvez-vous expliquer (ou un lien vers une explication) pourquoi java.io.File est un exemple intéressant?
  • File est intéressant parce qu'il est susceptible de faire confiance à un être immuable, et donc conduire à TOCTOU (Moment De l'enregistrement/au Moment De l'Utilisation) des attaques. Le code de confiance vérifie que le File un chemin d'accès, puis utilise le chemin d'accès. Un sous-classé File peut changer de valeur entre les vérifier et de les utiliser.
InformationsquelleAutor Anand | 2012-09-06
  1. 120

    Si vous ne cochez pas la classe final, il pourrait être possible pour moi d'un coup à faire de votre apparence immuable classe mutable. Considérons par exemple ce code:

    public class Immutable {
     private final int value;

     public Immutable(int value) {
         this.value = value;
     }

     public int getValue() {
         return value;
     }
}

    Maintenant, supposons que je ne les suivants:

    public class Mutable extends Immutable {
     private int realValue;

     public Mutable(int value) {
         super(value);

         realValue = value;
     }

     public int getValue() {
         return realValue;
     }
     public void setValue(int newValue) {
         realValue = newValue;
     }

    public static void main(String[] arg){
        Mutable obj = new Mutable(4);
        Immutable immObj = (Immutable)obj;              
        System.out.println(immObj.getValue());
        obj.setValue(8);
        System.out.println(immObj.getValue());
    }
}

    Avis que, dans mon Mutable sous-classe, j'ai surchargé le comportement de getValue lire une nouvelle, mutable champ déclarée dans mon sous-classe. En conséquence, votre classe, qui au départ semble immuable, n'est vraiment pas immuable. Je peux passer ce Mutable objet dans une Immutable objet est prévu, ce qui pourrait faire Très Mal de Choses à code en supposant que l'objet est vraiment immuable. Le marquage de la classe de base final empêche que cela se produise.

    Espérons que cette aide!

    • Si je ne Mutable m = new Mutable(4); m.setValue(5); Ici, je joue avec Mutable objet de classe, pas Immuable de la classe de l'objet.Donc, je suis encore confus pourquoi Immuable de la classe n'est pas immuable
    • Imaginez que vous avez une fonction qui prend un Immutable un argument. Je peux passer un Mutable objet de cette fonction, depuis Mutable extends Immutable. À l'intérieur de cette fonction, alors que vous pensez que votre objet est immuable, je pourrais avoir un thread secondaire qui passe et les changements de la valeur que la fonction s'exécute. Je pourrais aussi vous donner un Mutable objet que la fonction de magasins, puis plus tard de modifier sa valeur à l'extérieur. En d'autres termes, si votre fonction prend la valeur est immuable, il pourrait facilement se casser, car je pourrais vous donner un objet mutable et le changer plus tard. Cela fait-il sens?
    • cela peut paraître stupide, mais vraiment, je ne suis pas encore clair..prenons un exemple dire que j'ai la méthode void plaisir(Immuable i)..je passe cette méthode Mutable objet de dire m..maintenant, comment puis-je changer l'objet. Pouvez-vous expliquer, en référence à l'exemple de code ou si vous pouvez donner un autre exemple, je suis très bien avec ça aussi..
    • La méthode que vous passez l' Mutable objet ne va pas changer l'objet. Le souci est que cette méthode pourrait supposer que l'objet est immuable quand il ne l'est pas vraiment. Par exemple, la méthode pourrait supposer que, depuis, il pense que l'objet est immuable, il peut être utilisé comme clé dans une HashMap. Je ne puis rompre cette fonction en passant dans un Mutable, en attente pour le stockage de l'objet comme une clé, puis en modifiant la Mutable objet. Maintenant, les recherches dans ce HashMap sera un échec, car j'ai changé la clé associée à l'objet. Cela fait-il sens?
    • Oui, j'en ai maintenant..faut dire que c'était une super explication..a fallu un peu de temps à comprendre si
    • mais après avoir hérité de l'immuable classe aussi nous ne sommes pas en mesure de modifier la variable "valeur". Suis-je le droit??
    • C'est correct. Toutefois, il n'a pas vraiment d'importance, puisque le substituée fonctions jamais référence à cette variable de nouveau.
    • Vous n'avez pas besoin de faire de l'ensemble de la classe finale juste de la lecture... public final int getValue()
    • Pour le HashMap exemple, la hashCode méthode devra être final ainsi, et rien d'autre hérité de Object qui pourrait avoir un impact, qui est la raison pour laquelle la classe final est beaucoup plus simple.
    • Je suis d'accord avec votre évaluation de la table de hachage exemple, bien que tout en rendant l'ensemble de la classe finale pourrait être plus simple qui ne signifie pas qu'il est correct. Rendre l'ensemble de la classe finale met en œuvre une conception de l'architecture au-delà du minimum requis pour accomplir la fonctionnalité. Car il est probable que quelqu'un utilise ce type de structure dans une bibliothèque (à utiliser pour les autres), il est courtois de faire des minimes hypothèses au sujet de l'utilisation et d'en imposer les restrictions minimales nécessaires pour assurer le bon fonctionnement de la bibliothèque. Même si, au final, il nécessite plus de travail par la bibliothèque de l'auteur.
    • J'ai 100% d'accord. Personnellement je déteste la restriction "en aval" de l'utiliser. Si quelqu'un veut casser quelque chose, ils le peuvent. Donc, le but n'est pas de rendre impossible de faire la mauvaise chose, juste pour le rendre dur. private final membres est assez d'une barrière dans la plupart des cas. J'ai appelé les autres (souvent invisible) des méthodes qui m'ont piqué dans le passé, comme hashCode de sorte qu'ils n'ont pas été oubliés 😉
    • juste une clarification, ses pas immuable, même si l'état est mis à jour par classe native(d'où son déclarée) droit? si un champ est private final il sera toujours en mesure de mettre à jour dans la même classe donc la rupture immuable...corrigez-moi si je suis mal.
    • En quelque sorte je ne suis pas d'accord avec cela, car avec Immutable immObj = (Immutable)obj; - immuable de la classe VHR pointe vers un objet mutable, et il peut le faire parce que c'est super classe. Le Point ici est que l'objet est de mutable classe et pas immuable de la classe, si vous créez l'objet de immuable classe alors il serait toujours immuable.
    • Le souci ici est que si vous avez un objet de référence et la référence est de type Immutable, vous ne pouvez pas dire si c'est en se référant à un réel, honnête à la bonté Immutable objet ou si elle pointe vers un délicat Mutable objet qui peut réellement changer au fil du temps. Le casting est ici parfaitement sûr, mais cache le fait qu'un objet de référence qui indique que l'objet ne changera jamais réellement points pour quelque chose qui peut vraiment changer au fil du temps.
    • Donc, je peux certainement apprécier cette réponse, mais même si je n'en suis pas 100% d'accord avec @Laurence Gonsalves réponse, je ne peux pas aider, mais mettre en place Mockito pour une non-classe finale lorsque les moqueries. Comment obtenez-vous autour de qui?
    • Parce que! obj et immObj point à la même instance.
    • Il est très clair et simple à comprendre! Merci!!!! C'est de m'aider.

    InformationsquelleAutor templatetypedef
  2. 37

    Contrairement à ce que pensent beaucoup de personnes, faire un immuable classe final est pas nécessaire.

    La norme argument pour rendre immuable classes final est que si vous ne le faites pas, alors les sous-classes peuvent ajouter de la mutabilité, violant le contrat de la super-classe. Les Clients de la classe d'assumer l'immuabilité, mais seront surpris quand quelque chose se transforme sous eux.

    Si vous prenez cet argument à sa logique extrême, puis tous méthodes final, sinon une sous-classe peut remplacer une méthode dans un sens qui ne sont pas conformes au contrat de sa super-classe. Il est intéressant de noter que la plupart des programmeurs Java voir ce que ridicule, mais sont en quelque sorte d'accord avec l'idée que l'immuable classes doivent être final. Je suppose que cela a quelque chose à faire avec des programmeurs Java en général pas totalement à l'aise avec la notion de l'immuabilité, et peut-être une sorte de flou réflexion sur les multiples sens de la final mot-clé dans Java.

    Conforme au contrat de votre super-classe n'est pas quelque chose qui peut ou doit toujours être appliqué par le compilateur. Le compilateur peut appliquer certains aspects de votre contrat (par exemple: au moins un ensemble de méthodes et de leur type de signatures), mais il ya de nombreuses parties de contrats atypiques qui ne peut être exécutée par le compilateur.

    Immutabilité est une partie du contrat d'une classe. C'est un peu différente de certaines des choses que les gens sont plus, parce qu'il dit ce que la classe (et toutes les sous-classes) ne peut pas faire, alors que je pense que la plupart de Java (et plus généralement de la POO) les programmeurs ont tendance à penser à des contrats relatifs à la signification d'une classe peut faire, pas ce qu'il ne peut pas faire.

    Immutabilité affecte également plus qu'une unique méthode qu'il affecte l'ensemble de l'instance — mais ce n'est pas vraiment très différent de la façon dont equals et hashCode en Java de travail. Ces deux méthodes ont un contrat spécifique énoncée dans Object. Ce contrat très attentivement dispose de choses que ces méthodes ne peut pas faire. Ce contrat est fait plus précis dans les sous-classes. Il est très facile de remplacer equals ou hashCode d'une manière qui constitue une violation du contrat. En fait, si vous remplacez un seul de ces deux méthodes sans l'autre, les chances sont que vous êtes violation du contrat. Devrait donc equals et hashCode ont été déclarées final dans Object pour éviter cela? Je pense que la plupart diront qu'ils ne devraient pas. De même, il n'est pas nécessaire pour rendre immuable classes final.

    Cela dit, la plupart de vos classes, immuable ou pas, probablement devrait être final. Voir Efficace Java Deuxième Édition Article 17: "la Conception et le document de l'héritage ou de l'autre de l'interdire".

    Donc une version correcte de votre étape 3 serait: "Faire la classe finale ou lors de la conception de sous-classement, de documenter clairement que toutes les sous-classes doivent continuer à être immuable."

    • Il est intéressant de noter que Java "s'attend à", mais ne fait pas valoir que compte tenu de deux objets X et Y, la valeur de X.equals(Y) sera immuable (tant que X et Y continuer à se référer aux mêmes objets). Elle a les mêmes attentes concernant les codes de hachage. Il est clair que personne ne devrait s'attendre au compilateur de faire respecter l'immutabilité des relations d'équivalence et des codes de hachage (car il tout simplement ne peut pas faire). Je ne vois aucune raison pour laquelle les gens devraient s'attendre à être appliquées à d'autres aspects d'un type.
    • Aussi, il y a beaucoup de cas où il peut être utile de disposer d'un type abstrait dont le contrat spécifie l'immuabilité. Par exemple, on peut avoir un résumé ImmutableMatrix type qui, étant donné une paire de coordonnées, renvoie une double. On pourrait en déduire une GeneralImmutableMatrix qui utilise un tableau comme un magasin de sauvegarde, mais on peut également, comme par exemple le ImmutableDiagonalMatrix qui stocke tout simplement un tableau d'éléments le long de la diagonale (la lecture de l'élément X,Y donnerait Arr[X] si X==y et zéro sinon).
    • J'aime cette explication le meilleur. Toujours en train de faire un immuable classe final limite son utilité, en particulier lors de la conception d'une API destinée à être étendue. Dans l'intérêt de fil de sécurité, il est logique de faire de votre classe aussi immuables que possible, mais le garder extensible. Vous pouvez faire les champs protected final au lieu de private final. Puis, de manière explicite à l'établissement d'un contrat (dans la documentation) sur des sous-classes en adhérant à l'immutabilité et enfilez-les garanties de sécurité.
    • +1 - je suis avec vous tout le chemin jusqu'à ce que le Bloch devis. Nous n'avons pas d'être paranoïaque. 99% de codage sont coopérative. Pas grave si quelqu'un a vraiment besoin de modifier quelque chose, laissez-les. 99% d'entre nous ne sont pas de l'écriture de certains d'Api comme la Chaîne ou de la Collection. Beaucoup de Bloch conseils, malheureusement, sont basés sur ce genre de cas d'utilisation. Ils ne sont pas vraiment utile pour la plupart des programmeurs, surtout les nouveaux.
    InformationsquelleAutor Laurence Gonsalves
  3. 19

    Ne marque pas l'ensemble de la classe finale.

    Il y a des raisons valables pour permettre aux est immuable de la classe à être étendu comme indiqué dans les autres réponses afin de marquage de la classe comme final n'est pas toujours une bonne idée.

    C'est mieux pour marquer vos biens privés et finale, et si vous voulez protéger le "contrat" marque de votre getters comme définitive.

    De cette façon, vous pouvez autoriser la classe d'être étendu (oui peut-être même par une mutable classe) cependant les aspects immuables de votre classe sont protégés. Les propriétés sont privées et ne peuvent pas être accessibles, des getters pour ces propriétés sont définitives et ne peuvent pas être remplacées.

    Tout autre code qui utilise une instance de votre immuables de la classe sera en mesure de compter sur les aspects immuables de votre classe, même si la sous-classe, il est transmis est mutable dans d'autres aspects. Bien sûr, puisqu'il faut une instance de votre classe, il ne voulait même pas connaître l'existence de ces autres aspects.

    • Je préfère encapsuler tous les aspects immuables dans une autre classe et de l'utiliser par le biais de la composition. Il serait plus facile de raison pour que le mélange changeant et immuable de l'état dans une unité de code.
    • Tout à fait d'accord. Composition serait un très bon moyen d'y parvenir, à condition que votre mutable classe contient votre immuables de la classe. Si votre structure est dans l'autre sens, ce serait une bonne solution partielle.
    InformationsquelleAutor Justin Ohms
  4. 5

    Si elle n'est pas finale, puis quelqu'un pourrait étendre la classe et de faire ce qu'ils souhaitent, comme la fourniture de setters, l'occultation de votre variables privées, et, essentiellement, le rendant mutable.

    • Bien que vous avez raison, il n'est pas clair pourquoi le fait que vous pouvez ajouter mutable comportement serait nécessairement casser des choses si la classe de base des champs sont tous privés et finale. Le vrai danger est que la sous-classe peut transformer une immuable précédemment objet dans un objet mutable en substituant le comportement.
    InformationsquelleAutor digitaljoel
  5. 4

    Que les contraintes des autres classes de l'extension de votre classe.

    finale de la classe ne peut pas être prolongé par d'autres classes.

    Si une classe d'étendre la classe que vous voulez faire comme immuable, il peut changer l'état de la classe en raison de l'héritage de principes.

    Juste préciser "il peut changer". Sous-classe peut remplacer superclasse genre de comportement à l'aide de la redéfinition de méthode (comme templatetypedef/Ted Hop réponse)

    • C'est vrai, mais pourquoi est-il nécessaire ici?
    • oui c'est vrai, pourquoi est-il nécessaire?
    • Vous êtes trop rapide. Je suis d'édition ma réponse avec les points d'appui.
    • Dès maintenant votre réponse est tellement vague que je ne pense pas que cela répond à la question à tous. Qu'entendez-vous par "il peut changer l'état de la classe en raison de l'héritage de principes?" Sauf si vous savez déjà pourquoi vous devez marquer final, je ne vois pas comment cette réponse aide.
    InformationsquelleAutor kosa
  6. 2

    Pour la création immuable de la classe, il n'est pas obligatoire de marquer la classe finale.

    Permettez-moi de prendre un tel exemple à partir des classes java lui-même "BigInteger" la classe est immuable, mais ce n'est pas définitive.

    Fait l'Immuabilité est un concept selon lesquelles l'objet créé alors il ne peut pas être modifié.

    Nous allons réfléchir à partir de la JVM point de vue, à partir de la JVM point de vue de tous les threads doivent partager la même copie de l'objet et il est entièrement construit avant n'importe quel thread accède à celle-ci et l'état de l'objet ne change pas après sa construction.

    Immutabilité signifie qu'il n'existe aucun moyen yo changement de l'état de l'objet une fois qu'il est créé et ce qui est réalisé par les trois règles qui en fait le compilateur de reconnaître que la classe est immuable et ils sont comme suit :-

    • tous les non champs privés devrait être final
    • assurez-vous il n'y a pas de méthode dans la classe qui peut modifier les champs de l'objet, soit directement ou indirectement
    • toute référence à l'objet défini dans la classe ne peut pas être modifié à l'extérieur de la classe

    Pour plus d'informations, reportez-vous à l'URL ci-dessous

    http://javaunturnedtopics.blogspot.in/2016/07/can-we-create-immutable-class-without.html

    InformationsquelleAutor Tarun Bedi
  7. 1

    Si vous ne le faites pas final je peux l'étendre et de le rendre non mutable.

    public class Immutable {
  privat final int val;
  public Immutable(int val) {
    this.val = val;
  }

  public int getVal() {
    return val;
  }
}

public class FakeImmutable extends Immutable {
  privat int val2;
  public FakeImmutable(int val) {
    super(val);
  }

  public int getVal() {
    return val2;
  }

  public void setVal(int val2) {
    this.val2 = val2;
  }
}

    Maintenant, je peux passer FakeImmutable à toute la classe qui attend Immuable, et il ne se comportera pas comme le contrat prévu.

    • Je pense que c'est à peu près identique à ma réponse.
    • Oui, vérifié la moitié du chemin par le biais de l'affichage, pas de nouvelles réponses. Et puis quand il est affiché, il y a la vôtre ont été, 1 minute avant moi. Au moins nous n'avons pas le même nom pour tout.
    • Une Correction : Dans FakeImmutable classe, un Constructeur nom doit être FakeImmutable PAS Immuable
    • Merci, fixe.
    InformationsquelleAutor Roger Lindsjö
  8. 0

    Supposons que la classe suivante n'étaient pas final:

    public class Foo {
    private int mThing;
    public Foo(int thing) {
        mThing = thing;
    }
    public int doSomething() { /* doesn't change mThing */ }
}

    C'est apparemment immuable, parce que même les sous-classes ne pouvez pas modifier mThing. Cependant, une sous-classe peut être mutables:

    public class Bar extends Foo {
    private int mValue;
    public Bar(int thing, int value) {
        super(thing);
        mValue = value;
    }
    public int getValue() { return mValue; }
    public void setValue(int value) { mValue = value; }
}

    Maintenant un objet qui est assignable à une variable de type Foo n'est plus garanti pour être mmutable. Cela peut causer des problèmes avec des choses comme le hachage, l'égalité, la concurrence, etc.

    InformationsquelleAutor Ted Hopp
  9. 0

    La conception en elle-même n'a aucune valeur. Le Design est toujours utilisé pour atteindre un but. Quel est le but ici? Nous ne voulons réduire la quantité de surprises dans le code? Voulons-nous éviter les bugs? Sommes-nous en suivant aveuglément les règles?

    Aussi, le design a un coût. Chaque conception qui mérite ce nom signifie que vous avez un conflit d'objectifs.

    Avec cela à l'esprit, vous avez besoin de trouver des réponses à ces questions:

    1. Combien évident bugs cela empêchera?
    2. Combien de bogues subtils cela empêchera?
    3. Quelle sera la fréquence de ce faire un autre code plus complexe (= plus enclins à faire des erreurs)?
    4. Est-ce à rendre le test plus facile ou plus difficile?
    5. Comment sont bons développeurs dans votre projet? Combien d'orientation avec un marteau-ils besoin?

    Dire que vous avez beaucoup de junior les développeurs de votre équipe. Ils tentent désespérément de toute chose stupide juste parce qu'ils ne savent pas de bonnes solutions à leurs problèmes, encore. Faire de la classe finale pourrait empêcher les insectes (bon), mais pourrait aussi les faire venir avec "intelligent" des solutions telles que la copie de l'ensemble de ces classes dans une mutable partout dans le code.

    D'autre part, il sera très difficile de faire une classe final après il est utilisé partout, mais il est facile de faire un final classe non-final plus tard si vous trouvez que vous avez besoin de le prolonger.

    Si vous utilisez correctement les interfaces, vous pouvez éviter le "j'ai besoin de faire ce mutable" problème en utilisant toujours l'interface, puis, plus tard, l'ajout d'une mutable mise en œuvre lorsque le besoin s'en fait sentir.

    Conclusion: Il n'y a pas de "meilleure" solution pour répondre à cette question. Cela dépend du prix que vous êtes prêt et que vous avez à payer.

    InformationsquelleAutor Aaron Digulla
  10. 0

    Le défaut de sens de equals() est le même que le référentiel de l'égalité. Pour immuable types de données, ce qui est presque toujours mauvais. Donc, vous avez à redéfinir la méthode equals (), pour le remplacer par votre propre mise en œuvre. lien

    InformationsquelleAutor Anitha B S