Using Inheritance -- clarification needed ?

[vivekian]

Hi,

Have this following hierarchy which am implementing for a networking
program. The base class 'ASocket' is the base class from which
'AListener' and 'ATalker' inherit . None of the functions in the
derived classes would override functions from the base class. The
derived classes would extend the base class. A couple of doubts :

1. Should the functions in the base class be declared virtual ?

2. Is this a good way to go about things or should one make ASocket an
abstract base class ? ( thinking in terms of interface based
programming )

3. The Inheritance topic in C++ FAQ slightly confuses me .. It talks a
lot about protected inheritance .. should that be a concern for such a
situation.

Thanks in advance.

[Alf P. Steinbach]

* vivekian:

Have this following hierarchy which am implementing for a networking
program. The base class 'ASocket' is the base class from which
'AListener' and 'ATalker' inherit . None of the functions in the
derived classes would override functions from the base class. The
derived classes would extend the base class. A couple of doubts :

1. Should the functions in the base class be declared virtual ?
When you're not overriding anything there's no apparent reason.

But are you sure you're not overriding anything?

E.g., if you're deleting an object via an ASocket* pointer, then you
should be overriding the destructor, which should then be virtual.

2. Is this a good way to go about things or should one make ASocket an
abstract base class ? ( thinking in terms of interface based
programming )
AFAICS you don't provide enough information to answer that.

3. The Inheritance topic in C++ FAQ slightly confuses me .. It talks a
lot about protected inheritance .. should that be a concern for such a
situation.

AFAICS you don't provide enough information to answer that.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[vivekian]

Alf P. Steinbach wrote:

2. Is this a good way to go about things or should one make ASocket an
abstract base class ? ( thinking in terms of interface based
programming )

AFAICS you don't provide enough information to answer that.

3. The Inheritance topic in C++ FAQ slightly confuses me .. It talks a
lot about protected inheritance .. should that be a concern for such a
situation.

AFAICS you don't provide enough information to answer that.

okay, my bad.
ASocket has the following methods -- openSocket () , closeSocket () ,
bind() which are common to both the derived classes and would remain
the same for both of them. AListener would have specific methods to
listen to incoming UDP packets and ATalker would have the ability to
broadcast such packets.

Though this is probably a one time coding effort, but was thinking if
lets say some time later the class needs to add TCP functionality , so
then requirements would change, the openSocket and closeSocket function
would require different arguments. In what way should my thought
process and design be to forsee future extensibility ? ( Thinking in
terms of direction inversion principle ) and thus asking about abstract
class ?

Also the Atalker and Alistener class would be used by other classes as
in a composition relationship ? This is where the c++ FAQ confuses me
e.g. "I've been told to never use protected data, and instead to always
use private data with protected access functions. Is that a good
rule?". Am not sure if all the FAQ are relevant here ?

thanks again .

[Noah Roberts]

vivekian wrote:
In what way should my thought

process and design be to forsee future extensibility ?

It shouldn't. You should design and implement what you need in the
most abstract way you can think of with the least amount of
dependencies between modules. That is all. Let the future establish
itself. Reasons:

1) you spend all your time in analysis paralisys and never get anything
done if you try to think of every possibly future need.

2) you can't think of every possibly future need so why try?

3) Just following some guidelines and avoiding pitfalls makes it easy
to make changes later.

All you need to do is prepare yourself for the possibility of having to
make changes to the code base by keeping the smells to a minimum.
Learn how to refactor...reco gnize bad code and learn how to turn it
into good code and how to take good code and change it to match new
needs.

With that in mind...inherita nce is the strongest binding you can create
between two modules short of friendship. Avoid when not needed.

Yes, I got all that from books but it also applies very well in the
real world.

[vivekaseeja]

Noah Roberts wrote:

vivekian wrote:
In what way should my thought

process and design be to forsee future extensibility ?
It shouldn't. You should design and implement what you need in the
most abstract way you can think of with the least amount of
dependencies between modules. That is all. Let the future establish
itself.

Yes , makes sense. So does that translate into using abstract classes
to minimize dependencies. ? e.g. in my case .. there would be an
abstract base class called ASocket from which both UDPSocket and
TCPSocket could derive ?
With that in mind...inherita nce is the strongest binding you can create
between two modules short of friendship. Avoid when not needed.

This is the part which confuses me most. When do i use inheritance ?
while coding when there are two classes which share common
functionality it makes so much sense to put this common functionality
in a base class and then specialize with derived classes. But then
everyone says 'use inheritance with caution' and makes me think twice..
so lets say in the above case , when ATalker and AListener have
functions in common , is it not right for them to derive from ASocket ?