C++Talk.NET

RenjithMohan · Guest

It has been stated in umpteen places that Public Inheritance should
only be used
1) When there is an abstraction which can be modeled as an interface
2) When there is Subsitutablity ( LSP)

The thing I am concerned is whether these are the only cases that I can
use Public Inheritance.
The situation goes like this . I have several DB classes in C++ which
share some code like the Open , Close , IsOpen functions.So to enable
this Design

I create a base class which implements these functions and all my other
Derived DB classes inherit publically from this since clients of these
classes would be calling these functions
class BaseDB
{
void Open();
void Close();
void IsOpen();
const char* GetError();
};

class ClientDB : public BaseDB
{
void GetClientData();
....
};
class MMDB : public BaseDB
{
bool CheckIfClaimExists();
};

The problem we are facing is that we know that there are some clients
which just use MMDB and ClinteDB without using the BaseDB . So would it
be worthwhile to write stub functions in all such DB classes and
contain the BaseDB or to use public inheritance to avoid writing such
stub code.

What is inherently wrong in this design from a pragmatic point of view?.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Carl Barron · Guest

In article <1124813382.064790.106980 (AT) g44g2000cwa (DOT) googlegroups.com>,
RenjithMohan <renjithmohan (AT) hotmail (DOT) com> wrote:

tony_in_da_uk@yahoo.co.uk · Guest

The guidelines you mention are more applicable to situations with
polymorphic hierarchies where the client is regularly passing derived
types into functions that rely on the relationship with the base class.
These functions, if poorly implemented, can cause you trouble. For
example, by updating only the base-class component during a by-value
copy. Still, in your situation the clients will be dealing with very
few objects, and are unlikely to routinely apply hacked-together
polymorphic algorithms to them, so there's little risk.

Separately, there is a potential physical design argument for
insulating the client from changes to the header defining BaseDB, but
it would be a permature optimisation to write forwarding functions
unless that header pulled in a lot of other headers, and had an
avoidable adverse affect on client compilation times.

Cheers, Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

RenjithMohan · Guest

Actually in this case, the BaseDB represents a convenient set of
functions to call into the DB API layer which is ADO in this case. So
changing BaseDB should in fact affect all its siblings since they all
depend on the DB API layer.
So the question actually is, in the absence of polymorphic functions
should we use public inheritance against community wisdom or deal with
not too helpful forwarding functions just for the sake for "stronger
encapsulation" ?.
I didnt see this case listed as an exceptional situation to use public
inheritance in the absence of polymorphic functions .

Joe · Guest

In this situation, I would consider using private inheritance and
exposing the functions explicitly with 'using' statements.

class ClientDB : private BaseDB
{
public:
using BaseDb::Open;
using BaseDb::Close;
using BaseDb::IsOpen;
using BaseDb::GetError;
}

This for requires a little more typing, but it prevents accidental use
of the polymorphism and makes explicit the pieces you wish to expose
from BaseDB.

joe

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Tony Delroy · Guest