On 26 Oct 2005 09:00:42 -0700,
fo*******@hotmail.com wrote:
I've come full circle on a design here. Consider the case where I've
got two modes of operation, uni-cast or multi-cast.
In either mode you can transmit(send) and/or receive.
The distinction between the two modes amounts to a set of vendor APIs.
When transmitting, to estabilish a connection in uni-cast mode I'll do:
....
Just uncertain if I'm on the right track here. So I'd appreaciate some
feedback.
Thanks in advance.
Your design entangles the receiver and transmitter in a way that the user
doesn't care about. In other words, constructing a receiver and then passing a
reference to it to the constructor of a transmitter is nonsensical, because:
- The transmitter object shouldn't care what receiver you're using
- A transmitter and receiver must be created together. What does it mean when
you construct a receiver but not a corresponding transmitter?
I would turn the design on its head and encapsulate the vendor-specific side
of things, and then offer up non vendor-specific interfaces to the
application, e.g.
class Receiver /* interface */
{
public:
virtual void Receive() = 0;
};
class Transmitter /* interface */
{
public:
virtual void Transmit() = 0;
};
class Connection
{
public:
virtual Receiver& getReceiver();
virtual Transmitter& getTransmitter();
protected:
Connection(); // Class must be inherited from
};
class MulticastConnection: public Connection
{
public:
/* ... */
};
class UnicastConnection: public Connection
{
public:
/* ... */
};
The user's code would look something like:
Connection* pConnection = new MulticastConnection();
Receiver& receiver = pConnection->getReceiver();
Transmitter& transmitter = pConnection->getTransmitter();
or
Connection* pConnection = new UnicastConnection();
Receiver& receiver = pConnection->getReceiver();
Transmitter& transmitter = pConnection->getTransmitter();
You can use lazy evaluation to allow the user to get a transmitter from a
connection, but not a receiver, or vice versa.
-dr
