1

Here, I learned that sub-classing violates encapsulation:

it violates encapsulation, since the implementations of the superclass and subclass become tightly coupled

For instance, If we consider below Java syntax, a class has access to all the fields and methods of its super class provided they are not declared private.

class Person{
    private String name;
    String address;
    //methods of class Person
}

class Employee extends Person{
    float salary;
    private Employee immedateManager;
    private raiseSalary(float raise){...}
}

class Manager extends Employee{
    String department;

    void test(){
        name = "Fred";   //compiler error, could not break encapsulation
        salary = 70000.00f;
        address = "somewhere";
        immediateManager = "Slate"; //compiler error, could not break encapsulation
        raiseSalary(1234.0);    //compiler error, could not break encapsulation
    }
}

So, if the representation part of type abstraction (Java class) is declared private, then how does one understand before saying that, sub-classing violate encapsulation?

  • 2
    There are two conflicting opinions about this; let me present the one (other posters will undoubtedly present the other): It doesn't violate encapsulation because, per Liskov substitability, the subclass object is a superclass object (Herbie IS_A Car as well as a Volkswagen). Therefore, all the use that herbie makes of the fuel_tank_volume value is OK, because it's from within the Car class and not from without. – Kilian Foth Jun 16 '15 at 7:13
1

It has nothing to do with privacy. An integral part of your class is no longer implemented inside your class. By definition that's a loss of encapsulation.

However, object-oriented programmers sometimes place an outsized importance on class-level encapsulation. The other problems with inheritance, such as coupling, are much more important, and the encapsulation loss shouldn't bother you in situations where inheritance is otherwise appropriate.

  • For your point: An integral part of your class is no longer implemented inside your class. You mean, no longer implemented in sub class? But Liskov principle says:if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program. This is a test before introducing inheritance.So, Can't I infer that it is equivalent to implementing in subclass for what you actually implemented in super class? – overexchange Jun 16 '15 at 17:02
  • Inheritance is certainly appropriate if you need substitutability. That doesn't mean you aren't trading off some loss of encapsulation, only that you've determined the trade off is worth it. – Karl Bielefeldt Jun 16 '15 at 17:09
  • when I say, it is equivalent to implementing in subclass for what you actually implemented in super class. Where is loss of encapsulation here? – overexchange Jun 16 '15 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.