Geek Answers Handbook

Immutablity in Java

I am trying to put things together in the definition of "immutability . "

Paragraph (3) here says, as one of the rules for creating immutable objects,

Do not let subclasses override methods. The easiest way to do this is to declare the class final ....

Overridden methods run on instances of subtasks (s). And, from what I know, an immutable class is one of the objects that are "cut out" in memory after they are created - not one of its members and, therefore, the object cannot be changed.

Putting them together, is the definition of "immutability" applicable to classes as well as to objects? Concluding methods, I forbid overriding methods with every extension of the class. I do not see how to refine the methods of an immutable class by adding objects to immutable ones.

+8
java immutability
source share
7 answers

If you document your class as immutable, users of this class can safely assume that any instance of this class is immutable.

The problem is that if you allow a subclass of your class, nothing prevents the subclass from adding mutable state and methods, or even overriding methods and causing them to change this new state. Thus, the assumption made by users of the class is falling apart. Creating a final class makes it impossible.

+7
source share

There are significant differences in the use of the final keyword.

Appliance ...

  • ... subclasses are forbidden in classes (and thus the method also overrides)
  • ... to methods prohibits method overrides
  • ... instance variables ensure the immutability of these fields and, therefore, also for whole objects, if they are specified for all, since the final variables can simply be written once, during construction.

Docs:

+1
source share

I do not see how to refine the methods of an immutable class by adding additional objects to immutable objects.

If the class is final , then its final methods are redundant; since nothing can happen from a class, nothing can override methods, regardless of whether they are declared final . If the class you defined is immutable, if it is final , there can be no subclasses that are not immutable (since there cannot be any subclasses at all).

+1
source share

I believe that if the objects of a class are immutable, then you can say that the class is also immutable. String objects are immutable, so you can say that the String class is immutable.

When you create your final methods, you prevent the execution of some unknown subclass:

 @Override public void yourMethod() { doSomeMutableThing(); }

This prevents the use of a subclass of inheritance and polymorphism to alter the data in your class. It also prohibits a subclass from introducing its own state, which can be mutable.

Consistency is not something you can just declare; you must enforce it using several methods built into the Java language. Creating your final methods is one of them.

+1
source share

Does the definition of "immutable" apply to classes as well as objects?

Seeing how a class is a plan of an object, yes?

The more important difference here is that - adding final everywhere does NOT make your class / object immutable. for everyone.

Consider this:

 final class Foobar { /* * in this context, final just means you can't rebind the variable. * it doesn't make the list immutable. */ final List<String> notReallyImmutableList; Foobar() { notReallyImmutableList = new ArrayList<String>(); } final void addToList(String string) { notReallyImmutableList.add(string); // totally legit if you have an instance of Foobar } }
+1
source share

Immutable means that the object CANNOT change. Thus, the standard String object in Java is immutable - you can pass it, you can store as many links as you want, but you cannot change it. If you want to change a string, you must use StringBuilder (or StringBuffer) to add or change.

But String is a class that is part of the embedded system, so its immutability can be taken at face value. If you want to create an immutable class, then you can do this only by providing methods that are guaranteed not to change its internal state. Since a class is usually valid, it is possible that part of the code may subclass your class just to change its internal state.

Thus:

  • Make all your fields internal. They should also be marked as final, as they should only be installed from the designer.
  • DO NOT return fields that are themselves objects unless they are also immutable.
  • Mark final object and all final methods
  • DO NOT provide any methods that may change the internal state
  • Operations such as clone (), add (), subtract (), split (), diff (), comb (), etc. that spit out new objects should not refer to an existing object or its fields on the safe side Use a deep copy to ensure thread safety.
  • If your object returns collections of other objects, use methods such as Collections.unmodifiableList (), unmodifiableMap (), etc. to stop people abusing these collections.
  • Similarly, if an object or any field implements interfaces intended for read / write operations, then throw exceptions when implementing any write operation.

Irreplaceability is a good quality for objects (especially those where ownership can be a problem, or concurrency), but the disadvantage is that you can build many discarded objects, and therefore they can be inefficient. So this is a compromise, and it depends on what you need for the objects, whether it's worth it.

+1
source share

Objects define behavior and state. immutability refers to the object that was once created will not change its internal state.

this simplifies work with threads, among other advantages, here is an example from guava immutable list. cant post links from im new ... http: //google-collections.googlecode .com / svn / trunk / javadoc / com / google / common / collect / ImmutableList. HTML

therefore, to answer your question, finalizing methods limits inheritance, but not immutability.

0
source share

More articles:


All Articles