Question: 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?](https://stackoverflow.com/q/19144062/2830834) but I didn't get understand anything from this post.

Can anybody please explain me the same?

Answer: 
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 field whose types are mutable 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.
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`.