Design question - interfacing with lots of different hardware architectures

[Angus]

Hello

My program works with different types of telephone system. Their interfaces
are all different.

But, of course, I don't want to have to write a different program for each
system. There is a LOT of code in the existing program which interfaces
with just one telephone system. I can re-use a lot of that. But I want a
flexible interface to the hardware.

My thinking is I would need to use some sort of polymorphic interface class.
Is this idea along the right lines:

class CTelephoneInter face
This class would have pure virtual functions eg to connect, disconnect,
request, configure, etc.

Then I would I would inherit:

class CSpecificSystem : public CTelephoneInter face

which would implement the base class pure virtual functions.

Any tips on implementation would be handy?

Then my next problem is that the telephone system sends event information.
some of it is unsolicited (ie no request generated the event). How would I
model that?

Any help would be much appreciated.

A

[blargg]

In article <g7************ *******@news.de mon.co.uk>,
"Angus" <no****@gmail.c omwrote:

...
class CTelephoneInter face
This class would have pure virtual functions eg to connect, disconnect,
request, configure, etc.

Then I would I would inherit:

class CSpecificSystem : public CTelephoneInter face

which would implement the base class pure virtual functions.

Just a side comment on naming: drop the C prefix and Interface suffix,
unless they add any useful information. So you have Telephone as the
base class, LucentTelephone as a derived class for example. Code reads
more naturally without stilted names.

[Daniel T.]

"Angus" <no****@gmail.c omwrote:

My program works with different types of telephone system. Their interfaces
are all different.

But, of course, I don't want to have to write a different program for each
system. There is a LOT of code in the existing program which interfaces
with just one telephone system. I can re-use a lot of that. But I want a
flexible interface to the hardware.

My thinking is I would need to use some sort of polymorphic interface class.
Is this idea along the right lines:

Probably not. I would only do the above is I had to change hardware at
runtime and I have a feeling that isn't the case.

One option that I consider better is a variation of the handle-body or
pimpl idiom.

Make your "Telephone. h" like this:

class Telephone {
struct Impl;
Impl* pimpl;
public:
void connect();
void disconnect();
// &c.
};

Now define the "Telephone::Imp l struct inside the Telephone.cpp file and
implement the functions as appropriate.

Now here is the cool bit. Write Multiple Telephone.cpp files
(ThisTelephone. cpp, ThatTelephone.c pp, SoOnTelephone.c pp) with each one
dedicated to a specific hardware.

Now when you compile for a particular hardware, use the appropriate cpp
file. QED.

Then my next problem is that the telephone system sends event information.
some of it is unsolicited (ie no request generated the event). How would I
model that?

Sounds like an Observer pattern would be appropriate.

[James Kanze]

On Aug 3, 3:30 am, "Daniel T." <danie...@earth link.netwrote:

"Angus" <nos...@gmail.c omwrote:

My thinking is I would need to use some sort of polymorphic
interface class. Is this idea along the right lines:

Probably not. I would only do the above is I had to change
hardware at runtime and I have a feeling that isn't the case.

The original poster didn't specify what his program was doing,
but polymorphic interfaces were certainly an important part of
the telephone systems I worked on. First, because you normally
connect more than one piece of equipment to the system, the
various equipment will be of different types, and you want to
handle them identically. And secondly, you're not allowed to
shut the system down, even when upgrading equipment. (The
hardware is specially designed so that you can safely remove a
PCB and insert another without removing power, or even stopping
operations on other PCB's on the same bus. Don't try that on
your PC, however.)

One option that I consider better is a variation of the
handle-body or pimpl idiom.

*IF* you just have one type per instance of the program, why
bother. Just define one header file, as many source files (or
libraries) as needed, and link in the appropriate one.

Make your "Telephone. h" like this:

class Telephone {
struct Impl;
Impl* pimpl;
public:
void connect();
void disconnect();
// &c.

};

Now define the "Telephone::Imp l struct inside the
Telephone.cpp file and implement the functions as appropriate.

If the different types require different data, yes.
Alternatively (although I prefer the above approach as well),
you can define an interface with a static member function to
construct instances, and put the data in the derived class.

Now here is the cool bit. Write Multiple Telephone.cpp files
(ThisTelephone. cpp, ThatTelephone.c pp, SoOnTelephone.c pp) with
each one dedicated to a specific hardware.

Now when you compile for a particular hardware, use the
appropriate cpp file. QED.

Then my next problem is that the telephone system sends
event information. some of it is unsolicited (ie no request
generated the event). How would I model that?

Sounds like an Observer pattern would be appropriate.

More or less. In larger systems, you typically use some sort of
central dispatcher: events are defined using ASN.1 (much like
LDAP), and objects interested in some events register for them
with a "discriminator" . But that may be overkill in many cases
(although it's necessary when the objects are distributed over a
network).

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Daniel T.]

James Kanze <ja*********@gm ail.comwrote:

"Daniel T." <danie...@earth link.netwrote:

"Angus" <nos...@gmail.c omwrote:

My thinking is I would need to use some sort of polymorphic
interface class. Is this idea along the right lines:

Probably not. I would only do the above is I had to change
hardware at runtime and I have a feeling that isn't the case.

The original poster didn't specify what his program was doing, but
polymorphic interfaces were certainly an important part of the
telephone systems I worked on. First, because you normally connect
more than one piece of equipment to the system, the various
equipment will be of different types, and you want to handle them
identically. And secondly, you're not allowed to shut the system
down, even when upgrading equipment. (The hardware is specially
designed so that you can safely remove a PCB and insert another
without removing power, or even stopping operations on other PCB's
on the same bus. Don't try that on your PC, however.)

That is a different problem than what I was trying to solve. If the OP
does need to deal with hot-swappable hardware, then my post may not
apply.

One option that I consider better is a variation of the
handle-body or pimpl idiom.

*IF* you just have one type per instance of the program, why
bother. Just define one header file, as many source files (or
libraries) as needed, and link in the appropriate one.

That's exactly what I'm suggesting in that case.