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

On Jul 16, 10:24am, Pallav singh <singh.pal...@gmail.com> wrote:
> 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.

On Jul 17, 4:00 am, "Daniel T." <danie...@earthlink.net> wrote:
> Pallav singh <singh.pal...@gmail.com> wrote:
> > 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

> 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).

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34