Design question regarding inheritance/polymorphism

[Angus]

Hi

I have designed a framework for working with devices. There is a
framework which has a generic device class - called devices. To
interface with an actual device the framework user would extend
devices like this:

class ABCDevice : public devices

Generally the program created will connect to a specific XYZ and there
will be many devices connected ot this XYZ. XYZ is not a device. Hope
that makes some sense.

The problem I am trying to get my head round is that it is useful to
retain a collection of devices. But if devices has been extended then
a collection of <Whatever>devices is required.

So do I just not bother with this functionality in the framework and
let the user of the framework write all the collection of devices
code? Or is there some way to write some of this code?

If I have a collection of devices (currently a list of device* 's),
then this is not so useful if framework user has extended devices. My
framework has no knowledge of all the possible different types of
specific device created.

Do I need some osrt of AddDevice() function - but then what to pass?

Any suggestions/help with my confusion would be much appreciated.

Angus

 

[alfps]

* Angus:

I have designed a framework for working with devices. There is a
framework which has a generic device class - called devices. To
interface with an actual device the framework user would extend
devices like this:

class ABCDevice : public devices

It's a good idea to stick to a single naming convention.

E.g. leading uppercase for type names.

Also, make sure that if an instance of a class represents a single
something, then the class name is not plural form, i.e. in this case
choose "Device" over "Devices".

Generally the program created will connect to a specific XYZ and there
will be many devices connected ot this XYZ. XYZ is not a device. Hope
that makes some sense.

The problem I am trying to get my head round is that it is useful to
retain a collection of devices. But if devices has been extended then
a collection of <Whatever>devices is required.

So do I just not bother with this functionality in the framework and
let the user of the framework write all the collection of devices
code? Or is there some way to write some of this code?

The C++ library, as well as Boost, already has lots of collection
classes.

Your job is (where practically necessary) to support those collection
classes & algorithms, not to invent collections and algorithms from
scratch.

If I have a collection of devices (currently a list of device* 's),
then this is not so useful if framework user has extended devices. My
framework has no knowledge of all the possible different types of
specific device created.
huh?


Do I need some osrt of AddDevice() function

Probably not.


Cheers & hth.,

- Alf

 

[jason.cipriani]

The problem I am trying to get my head round is that it is useful to
retain a collection of devices.  But if devices has been extended then
a collection of <Whatever>devices is required.

So do I just not bother with this functionality in the framework and
let the user of the framework write all the collection of devices
code?  Or is there some way to write some of this code?

There are many ways to write all of this code. If storing collections
of devices is something that a user is going to be doing fairly
frequently, and if functions in your framework exist to operate on
collections of devices, then it will make more sense for your
framework to provide some definition of what a collection of devices
actually is, rather than leaving it entirely up to the user.

If I have a collection of devices (currently a list of device* 's),
then this is not so useful if framework user has extended devices. My
framework has no knowledge of all the possible different types of
specific device created.

A collection *is* useful. If all of your devices derive from a common
base (e.g. Device), then you can store them in STL/Boost collections
(as alfps mentioned), e.g.:

std::list<Device *> devices;

Any user-defined Devices can be stored in that container, provided
that they also derive from Device.

Do I need some osrt of AddDevice() function - but then what to pass?

You do not *need* to define a function like that. All of the standard
container implementation provide some way of adding an element to the
container. E.g.:

Device *MyDevice = ...;
std::list<Device *> devices;
devices.push_back(MyDevice);

That said, if you want to implement your own container for some
reason, and it is backed by a standard container, then of course you
would have to provide a way for a client to add a device to your
container. As for what to pass to it, I'd imagine that you'd just pass
the Device you want to add. A simple example:


class Devices {
public:
void AddDevice (Device *dev) { devices_.push_back(dev); }
private:
std::list<Device *> devices_;
};


There are certainly some good reasons for wanting to hide the fact
that you are using a standard container, but it really depends on your
situation (e.g. you don't want to pass std::lists/vectors/etc. across
shared library interfaces, or you want to add some functionality
related to Devices that a standard container does not provide such as
the ability to query devices by some "device type" or something).


Jason

 

[H. S. Lahman]

Responding to Angus...

I think you need to put some words around your notion of 'framework'.
For example, are your devices SOA-like services for which your framework
provides high-level access by arbitrary clients like XYZ? Or is your
framework a COM-like IDE where everything, devices and XYZs, interact
within the framework environment? Or something else?


--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer

H. S. Lahman
(e-mail address removed)
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html