CODEWITHSUNDEEP
javaoopinheritanceencapsulation
Surf all day
Surf all day

Reputation: 51

How to make strong encapsulation when working with inheritance?

I am really new to this so I am sorry if this is too stupid. I am having troubles to decided which visibility to use when using inheritence in Java.

For what I read, to have a strong encapsulation you usually set your attributes to private and you access them with public methods.

But this is a no go when you have inherence? When I was reading Oracle documentation its says that only the public/protected members are going to inherit to the subclass. But if I do this, Am I breaking the encapsulation?

Meanwhile, I was using private attributes on my superclass and I was accessing these fields on my child class with public methods. For example:

abstract public class Person{

  private String name;

  Person(String name){
    this.name = name;
  }

  public String getName(){
    return this.name;
  }

  public void setName(String name){
    this.name = name;
  }
}

public class Employee extends Person {

  private int salary;

  Employee(String name, int salary){
    super(name);
    this.salary = salary;
  }

  public void getDescription(){
    return "Name is " + getName() + " and salary is " + this.salary;
  }

}

Upvotes: 3

Views: 1157

Answers (4)

LEO CHEN
LEO CHEN

Reputation: 2143

For the strong encapsulation reason, it is a proper way to set the attributes to private and access them with public methods such as mutators and accessors.

But this is a no go when you have inherence?

Yes, only the public/protected members can be inherited to the subclass, private class can not be passed to the subclass.

Modifier    Class Package Subclass World
public        Y      Y        Y      Y
protected     Y      Y        Y      N
no modifier   Y      Y        N      N
private       Y      N        N      N

Am I breaking the encapsulation?

Not really. The encapsulation by definition is a protective shield that prevents the data from being accessed by the code outside this shield and the data in a class is hidden from other classes. The use of protected members for inheritance allows the data from being accessed by the subclass.

However, the concept of the encapsulation is that the information/data inside the object is hidden, and the internal properties or methods of the object can only be obtained through the interface provided by the object itself. In other words, the details or logic inside the object are hidden, and other objects cannot understand and changed the internal details of the object unless the method/interface provided by the object is allowed.

To put it bluntly, we only need to understand the external for the object, and we do not need to understand the internal structure. For example, we can get the Employee information through getDescription(), but we don't need to know how we get the information. Consequently, this may seem as an application of the encapsulation.

public void getDescription(){
    return "Name is " + getName() + " and salary is " + this.salary;
} // void method can not return a value, modified to the following code
public void getDescription(){
    System.out.println( "Name is " + getName() + " and salary is " + this.salary);
}

Upvotes: 0

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

For what I read, to have a strong encapsulation you usually set your attributes to private and you access them with public methods.

For a strong/proper encapsulation you set your attributes to private. Full stop. You should not access those attributes through any methods, you should offer methods that use those attributes to implement some part of the business logic instead.

[...]its says that only the public/protected members are going to inherit to the subclass[...]

Everything is going to be inherited, it will only not be visible to the subclass. So it will be a part of the object, you just can't access it directly.

[using public/protected attributes] But if I do this, Am I breaking the encapsulation?

Yes. You almost always break encapsulation when you make internal state available, either directly (making it anything other than private), or using a "getter" or similar method.

Upvotes: 0

Andrew
Andrew

Reputation: 49606

Am I breaking the encapsulation?

You aren't breaking anything. Protected members are still not visible for the rest of the world (excluding the classes in the package, and the subclasses). 

Modifier    Class   Package Subclass    World
private       N        N       N          N
protected     Y        Y       Y          N

A protected field is absolutely fine if you need to have direct control over it and bypass getters/setters which may distort that access.

On the other hand, a private field makes sense when you don't play with the field a lot: private String name; and "Name is " + getName() are totally correct because you don't care what exactly will be returned - anything that represents the name will be sufficient.

As a rule of thumb, "use the most restrictive access level that makes sense for a particular member. Use private unless you have a good reason not to."

Upvotes: 0

Starmixcraft
Starmixcraft

Reputation: 397

Maybe look into the javadoc on visibility but in your case protected is the right keyword, you can also just leave out the visibility then it defaults to package

Upvotes: 0

Related Questions