Re: deriving a class with a subset of base class methods?
Gerhard Menzl wrote:
Ulrich Eckhardt wrote:
Gerhard Menzl wrote:
Composition has a much lower degree of coupling than inheritance.
It does, but is that also the case for /private/ inheritance? If I add or
remove private baseclasses is not externally visible, just as it isn't
visible with private members. However, in both cases it obviously
requires that you recompile client code. No, I don't think that private
inheritance is that much different to aggregation.
A private base class is not accessible, but it is certainly visible in
the sense that it incurs a physical (i.e. #include) dependency.
So does aggregation.
Changes to the interface of the base class invariably propagate to
clients of the derived class.
I object to the 'invariably' part in that statement, can you give an
example?
When private inheritance is used in combination with using directives
for the purpose of the original poster, i.e. for selective reuse,
changes to the interface of the private base class may even require
changes to (and not just recompilation of) client code. It ties
interface to implementation
Okay. let's see...
// case 1:
class wrapper1: private list<int>
{
using list<int>::iterator;
using list<int>::const_iterator;
using list<int>::begin;
};
// case 2
class wrapper2
{
list<int> m_container;
public:
typedef list<int>::iterator iterator;
iterator begin()
{ return m_container.begin(); }
typedef list<int>::const_iterator const_iterator;
const_iterator begin() const
{ return m_container.begin(); }
};
In both cases, the user of these classes is sufficiently decoupled from the
implementation. If we changed this to using vector<int> instead of
list<int>, no client code would have to be touched, only the using
declarations, typedefs or wrappers functions here would. In both variants,
the client code needs to be recompiled though. In fact I could even replace
wrapper1 with wrapper2 without changes to the client code, so even if I
lateron find that I don't want to wrap anything at all but completely roll
my own container I can still do that!
So, I can't imagine any change to the underlying container that would
require client code to be changed in one case but not the other. If we
replaced list<int> with map<int, int>, we would either have to change
client code so that it can work with iterators returning a pair<int,int>
instead of an int or we would have to provide iterator wrappers that
provide an int as value type.
Note: just for the record, I consider this client code buggy:
wrapper w;
std::list<int>::iterator x = w.begin();
....because the second line should read
wrapper::iterator x = w.begin();
With aggregration, it is easy to avoid these dependencies by
forward-declaring the class to be reused and keeping a pointer to a
dynamically allocated instance. This allows you to change the
implementation completely without even having to recompile client code,
except when you replace the implementation class completely, and even
then there is no need to change client code. In large projects, this can
make a big difference.
Yes, of course, PIMPL and similar compiler firewalls do make a difference,
but that's not the point I'm arguing. What I say is only that aggregating a
single foo object and privately deriving from foo is very similar.
Note: when you said 'invariably', if you meant that you can't replace an
object with a pointer when deriving from it I agree. However, just using a
smart pointer (e.g. boost::scoped_ptr) already lifts that limit, so even
that is not completely true.
class impl;
class X1
{
impl* i;
};
class X2:
scoped_ptr<impl>
{
};
Uli
--
Sator Laser GmbH
Gesch??ftsf??hrer: Michael W??hrmann, Amtsgericht Hamburg HR B62 932
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]