3
#include<iostream>

class A {
public:
  int a;
protected:
  void func() {
  std::cout<<"protected member"<<endl;
  }
};

class B:public A
{
public:
  using A::func;  //Isn't this violation of encapsulation?
};

int main(){
B b;
b.func();
return 0;
}

Why the above code runs successfully?

Does it not violate the concept of Encapsulation?

Correct me if I am wrong.

Shubham Batra
  • 1,278
  • 1
  • 14
  • 27
  • What does "encapsulation" mean? – Kerrek SB Sep 29 '15 at 17:42
  • It's up to the designer of B to decide what interface to use, including providing access to protected members of A. – Bo Persson Sep 29 '15 at 17:44
  • Why would the above code not run successfully? Why would it violate the concept of Encapsulation? Since it _doesn't_, you need to explain to us your mistaken belief, before we can correct it. – Lightness Races in Orbit Sep 29 '15 at 17:45
  • I see that you have also posted questions about Java. C++ and Java have lots of differences when it comes to the "concepts" of programming. They are very different languages in many ways. This is one of those. – Bo Persson Sep 29 '15 at 17:50
  • So it turns out that I need not explicitly inherit the protected members like this ` class B : protected A` . Correct me if I am still wrong. – Shubham Batra Sep 29 '15 at 17:54
  • Protected inheritance only means that the public members of A will also be protected in B. Private inheritance means that *everything* will be private in B. Whatever you do, all members of A will also be members of B. – Bo Persson Sep 29 '15 at 18:27
  • Thanks alot for clearing my misconceptions. – Shubham Batra Sep 30 '15 at 01:21

2 Answers2

4

This is an interesting question, and I think it highlights an important and often-overlooked aspect of encapsulation in c++.

My answer is that "yes, encapsulation has been violated, but not where you think". The actual violation was in declaring the method to be protected in the first place.

Your code demonstrates nicely the problem with the protected relationship with subclasses... they can de-protect you with ease. Another way of saying this is that if you're going to make a member protected, you may as well make it public because in reality protected is public if your subclasses want it to be.

What does this mean in practice?

It means that if you make a member function protected, it is forever part of your class's interface. Therefore you must treat is as seriously as you would any other public member function and indeed as if it were a public member function.

Which is to say that it should be as stateless as possible, with as few preconditions as possible and should you change the implementation, the logical effect on the object as a whole must remain unchanged.

Richard Hodges
  • 68,278
  • 7
  • 90
  • 142
  • Thanks, this is the explanation I wanted. – Shubham Batra Sep 29 '15 at 18:08
  • Indeed. Declaring implementation details as `protected` seems to be a common beginners' mistake. I remember making it myself when I was new at C++. As years of experience would later show, `protected` is rarely useful at all. Almost all members should be `public` or `private`. – Christian Hackl Sep 29 '15 at 19:04
2

The example that you are showing is not a violation of encapsulation, because subclasses are allowed to add public members on top of what they inherit, and they also are allowed to access protected members that they inherit.

In your case, B, a subclass of A, decided to add a new member function called func, whose implementation happens to consist of a single invocation of A::func.

Generally, protected members should be regarded part of interface of your class, along with its public members. Despite the fact that their visibility is limited to subclasses, protected members are not part of the class implementation, because any change to protected members naming or semantics need to be coordinated with changes to all subclasses of the class.

Sergey Kalinichenko
  • 714,442
  • 84
  • 1,110
  • 1,523