Encapsulation in JAVA

[Aneek Banerjee]

What is the way other than Access modifiers to implement Encapsulation in Java?

[Sidharth Khattri]

Aneek Banerjee wrote:What is the way other than Access modifiers to implement Encapsulation in Java?

As far as I know, encapsulation can be implemented only by using private access modifier.

[Aneek Banerjee]

Lets say if I make the instance variables final.Will it be count as Encapsulation?

[Sidharth Khattri]

Aneek Banerjee wrote:Lets say if I make the instance variables final.Will it be count as Encapsulation?

No, final does not count as encapsulation. Consider the following Example:

class test{
public final test t = new test();
}

though t cannot hold reference to any other object as it's final, but the state of test object that it is referencing to can be changed by any class as it's marked public and not private.

[T. Sharma]

In order to see how one can implement encapsulation in Java, let us see design smells associated with encapsulation. We identified three smells associated with encapsulation:

1. Lenient Encapsulation
This smell occurs when the declared accessibility of one or more members of an abstraction is more permissive than actually required.

For example, Rectangle class exposes its data members and hence Rectangle class from JDK suffers from Lenient encapsulation smell.

public class Rectangle extends Rectangle2D implements Shape, java.io.Serializable
{
    public int x;
    public int y;
    public int width;
    public int height;
                // rest of the members elided … 
}

2. Missing Encapsulation
This smell occurs when there exists global state (in the form of global variables, global data-structures, etc.) accessible to all abstractions in the software system.

For example, consider the following members defined in java.lang.System class:

public final static InputStream in = null;
public final static PrintStream out = null;
public final static PrintStream err = null;

Since they are declared coderanch, any code (i.e., other classes in JDK as well as application code) can access these members directly. Hence, these members are effectively global variables!

3. Unexploited Encapsulation
This smell arises when client code uses explicit type checks (using chained if-else or switch statements) instead of exploiting the variation in types encapsulated within a hierarchy.