Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

While inheriting a class in C++, user can specify the access specifier like,

class Base
    public int mem1;
    protected in mem2;

class Derived1 : **private** Base
    // mem1 will be private here.
    // mem2 will be private here.

class Derived2 : **protected** Base
    // mem1 will be protected here.
    // mem2 will be protected here.

class Derived2 : **public** Base
    // mem1 will be public here.
    // mem2 will be protected here.

But the same is not possible in Java, i.e. extends in java is always like "public" inheritance in C++.

Could someone explain the reason for this?

share|improve this question

closed as not constructive by Jimmy Hoffa, Martijn Pieters, Dynamic, Michael Durrant, MichaelT Mar 17 '13 at 23:44

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

One doesn't need a reason to omit a feature, one needs a reason (ideally, several good ones) to add it. – delnan Mar 17 '13 at 16:37
This can only be answered speculatively, voting to close. – Jimmy Hoffa Mar 17 '13 at 19:05
up vote 7 down vote accepted

Most of the benefits that private / protected inheritance give you can be easily achieved through encapsulation. Thomas Eding has provided some good examples of cases that could be made easier with the addition of private / protected inheritance, and while these are valid cases, workarounds exist that do not require private / protected inheritance and are more 'idiomatic' (in Java at least).

The developers of the Java language evidently felt that the cost in complexity needed to support private / protected inheritance (including multiple inheritance) outweighed the benefit that it would provide.

share|improve this answer
It is worth noting, that in C++ there are some important differences between private inheritance and inclusion as member, but they revolve around order of initialization and multiple inheritance and thus don't translate into the simpler object system of Java. – Jan Hudec Jul 22 '13 at 11:02
-1: "Any benefit that private / protected inheritance give you can be easily achieved through encapsulation." Wrong. I would agree with "Most benefits ..." – Thomas Eding May 6 '14 at 0:15
@ThomasEding Can you give an example of something that can be achieved through private / protected inheritance but not through encapsulation (or at least something that would take a good deal of work to accomplish with encapsulation)? I honestly can't think of one, but I'm open to being convinced. – p.s.w.g May 6 '14 at 14:51
Whoops, sorry bout that. Here are some examples in C++. (1) Suppose you want to internally consider class B as an A (B privately inherits from A) so you can polymorphically use it in some method. With composition, this can be done, but it is much messier. Here you would need to create a separate subclass A' (probably an inner class) that implements the functionality you use. You would also need to manually delegate changes to the parent B class (B makes A' a friend, A' accepts a reference to B). I suppose this isn't too hard to do, but it incurs a mess in the code. (Cont) – Thomas Eding May 6 '14 at 18:09
... (2) If you want B to access protected variables in A, private inheritance is again simpler to implement over composition. With composition, you could implement A' similarly as above, and/or raise the access of the protected variables. (3) Suppose you want a single shared static member variable that is the same exact variable across template instantiations. A solution is to privately inherit from a non-templated base class that has the static member. Composition cannot solve this problem, though other techniques could (such as friend-ing some other class with the member). – Thomas Eding May 6 '14 at 18:15

As Java does not have multiple inheritance and everything has to be (publicly) inherited from Object, there are no places in Java where private or protected inheritance would yield a valid program.

share|improve this answer

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