"Inheritance break Encapsulation "

P

Pallav singh

Hi

i find Following statement while reading Design pattern in C++
( author - Erich Gamma)
"Inheritance break Encapsulation " because inheritance exposes to
subclass the detail of its parent's Implementation
Is it correct ???

as we only expose interface ( function prototype) to derived class But
not how it being implemented

Kindly give urs View regarding it

Thanks
Pallav
 
P

paul

Hi

i find Following statement while reading Design pattern in C++
( author - Erich Gamma)
"Inheritance break Encapsulation " because inheritance exposes to
subclass the detail of its parent's Implementation
Is it correct ???

as we only expose interface ( function prototype) to derived class But
not how it being implemented

Kindly give urs View regarding it

What you are saying sounds correct, but to precise public inheritance
allows inheritance of interface while private inheritance allows
inheritance of implementation.
Also you should understand in what context the author made the above
statement. What you've quoted from the textbook seems to be only a
part of the topic.
 
J

James Kanze

Also from the book "With inheritance, the internals of parent
classes are often visible to subclasses." (note the use of
"often".)

For some definition of "internals". By my definition, if it's
visible to another class (including a derived class), it's not
"internal" (so obviously, the internals aren't visible).

Note well that in the case of C++, "private" does NOT
necessarily mean internal. Sometimes undesirably, but for
example, virtual functions (including pure virtual functions)
that the derived class is meant to override are usually private.
But because the derived class is meant to override them, they
are very much part of the "external" (published) interface.
Similarly, declaring a private copy constructor, in order to
prevent the compiler from generating a public one, has a very
definite impact on the external interface (and is usually done
precisely for that impact).
For example, if the parent class has protected
member-variables, or if the parent class calls virtual
member-functions from within other member-functions. In either
case, the derived class must know something about the base
classes implementation in order to ensure that the parent's
member-variables are used correctly and to understand how to
implement its virtual member-functions.

More generally, any time two classes collaborate in any way, one
must know something about the other. And derivation is
(usually) a very close form of collaboration. If weaker forms
can be used, they usually should be.
I generally only use inheritance to facilitate polymorphism,
my base classes rarely have anything more than pure virtual
member-functions.

That's probably the most frequent use in well written code
(although of course, the base class also has public functions
which call the private virtual functions). But there are
exceptions; even in a strictly OO world, the template method
pattern can be used, and mixins are occasionally useful. And
the C++ technique of derivation can be used to implement other
things than just OO inheritance (think of classes like
std::unary_function, for example, which only makes sense as a
base class, but doesn't contain a single virtual function).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top