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 CTelephoneInterface
This class would have pure virtual functions eg to connect, disconnect,
request, configure, etc.

Then I would I would inherit:

class CSpecificSystem : public CTelephoneInterface

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

 

[James Kanze]

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::Impl 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.cpp, SoOnTelephone.cpp) with
each one dedicated to a specific hardware.

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

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).