In immutable class why fields are marked as privat

问题:

What is the benefit of making fields private while creating an immutable class?

I have seen why while creating immutable class, fields are declared as private? but I didn't get understand anything from this post.

Can anybody please explain me the same?

回答1:

The best way to explain is with an example:

  public class Immutable {
     private final char[] state = "Hi Mom".getChars();

     public char[] getState() {
         return state.clone();
     }
  }

Here we have a properly encapsulated, immutable class. Nothing can change the state (modulo nasty reflective tricks).

Now lets JUST change the access on the field:

  public class Immutable {
     public final char[] state = "Hi Mom".getChars();

     public char[] getState() {
         return state.clone();
     }
  }

Note we are still making the defensive copy in getState ... as before ... but now someone can do this:

  Immutable mu = new Immutable();
  mu.state[1] = 'o';

... and our supposedly immutable object's state has changed.

That is ONE reason why it is a good idea to keep the fields private. (Obviously, this only applies to reference types.)

A SECOND reason is encapsulation. Declaring fields as private hides implementation details, which reduces the risk of unwanted cross-coupling. If I don't do this, then I (or some other programmer) might be tempted to write code that depends on the internals of Immutable. That is going to lead to problems if I need to change them; e.g. changing the type of state to String. Problems as in "lots more code to check / change".

A THIRD reason is that non-private (and particularly public) fields can be an impediment to subclassing. If I declare a field as public then, the I can't undeclare it in a subclass. If I want to hide the field or modify the behavior of the field in a subclass (by overriding) ... I can't. By contrast, if the field is private and access is via instance methods, I can override those methods in subclasses. Or I can choose to not use the field at all.

回答2:

The only reason for making final fields private is binary compatibility, and this actually holds true irrespective of whether the containing class is immutable or not.

A class C is said to offer binary compatibility to classes X and Y that use class C if class C can be refactored without having to recompile classes X and Y.

You only need to worry about binary compatibility if you are developing a library to be used by software that is written by others and therefore you have no control over. If you are in this situation, then you pretty much have to use full encapsulation, which means that you have to make all fields private and only access them via getters.

However, in the vast majority of cases, what we are developing is top-layer, self-contained application software, not libraries to be used by others. So, in the vast majority of cases, there is no good reason to make final fields of immutable classes private, it is just a widely held misconception. In a top-layer, self-contained application scenario you can always refactor everything and your IDE will accordingly refactor all references, so immutable classes do not need encapsulation.

Some of the answers suggest that if a field is not private, and it points to a mutable object, then someone might go and modify that mutable object, which is of course correct, but then we go into the philosophical question of what really is an immutable object. Can an object still be called immutable if it contains mutable objects? Is the mutability of an object dependent on the mutability of objects that it contains?

My rule is as follows:

There are two kinds of fields: contained and referenced, which can otherwise be thought of as owned and unowned. As an example, think of an Employee class: the name of the employee is contained/owned by the class, since each employee has their very own name. However, the Employee class may also contain a reference to a Department class, and of course each employee does not have their very own department, so the department is a referenced/unowned field.

A contained/owned field like Employee.name must of course be final and immutable in order for the owning class (Employee) to be immutable. Such a field does not need to be private, unless we are aiming for binary compatibility.

A referenced/unowned field like Employee.department also needs to be final if the referring class (Employee) is to be immutable, but it does not have to be immutable, and its immutability does not affect the immutability of the referring class. Even in this case, (and unless we are aiming at binary compatibility,) a referenced/unowned field generally does not need to be private, because there is still no issue of encapsulation: we are not going to be making a defensive copy of an employee department, that would be nonsensical.

So, unless we are aiming for binary compatibility, then both in the case of contained/owned immutable fields and referenced/unowned fields (which can be either mutable or immutable,) the fields can stay public final and everything will be fine.

回答3:

An object that is referred to by a public final reference-type field can still be modified through that field. (What you can't do is change the field to refer to a different object.)

To disallow unwanted modifications, you need to make the field private.

回答4:

public fields can be accessed from any class anywhere and modified. But making fields private and final and using constructor injection / defensive copies, you ensure that the class is completely immutable.

回答5:

Non-private fields may still be read-accessed - and if that field is an object, mutable operations on that object may be invoked.

Making the fields private will prevent this possibility.

回答6:

final class A{
   final List l = new ArrayList(); 
}

Suppose you have list, and you made this list as final it's reference not modified at all.

But this list is easily accessible to outer classes and they are easily modify it's contents.

so prevent that we have to add private access specifier.

回答7:

If you'll use public field other objects will be able to change state of your "almost-immutable" object which will break encapsulation and make it a mutable object.