If B does not override any functions in A I think you could make it work by creating another class that contains the implementation of B, without inheriting from A, and then have class B and C inherit that class.
1 2 3 4 5
class A {};
class Bimpl {};
class B : public A, public Bimpl {};
class C : public Bimpl/*, private A*/ {};
@Peter87 That's not my case unfortunately.
@keskiverto Cause I would need to create new setters for A's variables and hide the existing ones (not overloading).
With these sorts of questions, I reckon it's easier on everyone if you tell us the details of what you are trying to do. Then keskiverto and Peter87 et al. will probably be able to go straight to the point of how to best design the code :+)
You could adjust the access of level of the inherited members.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
class A {
public:
void set() {};
};
class B : public A {};
class C : public B {
using A::set; // Private
};
int main()
{
C c;
c.set(); // Eror: Cannot access private member
}
Conceptually, you're inheriting from one class (B), that has one interface. The fact that B's interface happens to be the way it is because of B inheriting from A, is neither here nor there - B is what it is, and you either expose its interface, or you don't.
I don't see a simple way to say "expose that part of B's interface that doesn't come from A, and hide that part that comes from A".
If C's interface doesn't include all of B's interface, then it isn't an "is-a" relationship; calling code cannot treat C as if it was B.
I suspect you're going to have to inherit privately from B, or (more simply) have B as a member of C. Then just create an interface for C that has the methods you want, and which call through to the equivalent methods on B, effectively making C partially a facade.
If there's an interface that you want both C and B to conform to, you could perhaps define an abstract class that B and C could both inherit from, if that's appropriate.
As MikeyBoy has pointed out, there could still be a design problem.
IMO, the explanation of what you are doing is still somewhat abstract. What is the purpose of the real life classes A B C ? Given this information, I am sure the others can tell you straight away how they would design it.
You could adjust the access of level of the inherited members.
Huh... I've never seen that before! Didn't know you could redefine the access level of a member like that. Thanks for showing how to do that.
@Xriuk
I still think that publicly inheriting from B, but then hiding parts of B's interface, leads to a somewhat unclear design, and possibly indicates that there's a bigger problem with your design. But since you seem reluctant to share with us why it is you want to do this, and what you're trying to achieve in domain terms, you haven't enabled us to help with that.