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 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.
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.