By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,437 Members | 1,337 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,437 IT Pros & Developers. It's quick & easy.

design quandry ..

P: n/a

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:

openConnection(/*stuff*/);
establishUConnection(/*stuff*/);
tearDownUConnection(/*stuff*/); <- destructor activity

In multi-cast mode I'll do:
openConnection(/*stuff*/);
establishMConnection(/*stuff*/);
tearDownMConnection(/*stuff*/); <- destructor activity

When receiving the mode of operation is irrelevant. ie. You'll perform
the same operation in _either_ mode. i.e
openConnection(/*stuff*/);
configureRxChannel(/*stuff*/); configure the receive channel
tearDownRxChannel( /* stuff */)

You're allowed to call openConnection once, independent of the mode.
For instance, if I desire to send and receive in multi-cast mode. I
call openConnection once. So now:
openConnection(/*stuff*/);
establishMConnection(/*stuff*/);
configureRxChannel(/*stuff*/); configure the receive channel
So the best I could come with is as follows:

struct Connections {}; // vendor stuff
struct Channels {}; // vendor stuff

class receiver()
{
public:
receiver(vector<Connections>& coVec,
vector<Channels>& chVec))
{
if (openConnection(coVec)) {}
if (configureRxChannel(chVec)) {}
}
~receiver() throw() { if ( tearDownRxChannel(/*stuff*/)) }
// miscellaneous functions for status info.
};

class uniC
{
receiver& ref
public:
//constructor for the case where you desire to send and receive
uniC (receiver& r)
: ref(r)
{}

// constructor for the case where i desire to send only.
uniC (vector<Connections>& coVec)
{ if (openConnection(coVec)) {} }

~uniC () throw() { if ( tearDownUConnection(/*stuff*/)){} }
bool establishUConnection(/*stuff*/) {}
};

class multiC
{
receiver ref;
public:
// for the case where you desire to send and receive
multiC(receiver& r)
: ref(r)
{}

// for the case where i desire to send only.
multiC(vector<Connections>& coVec)
{ if (openConnection(coVec)) {} }

~multiC() throw() { if ( tearDownMConnection(/*stuff*/)){} }
bool establishMConnection(/*stuff*/) {}
};

Just uncertain if I'm on the right track here. So I'd appreaciate some
feedback.

Thanks in advance.

Oct 26 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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
Oct 27 '05 #2

P: n/a

|| You can use lazy evaluation to allow the user to get a transmitter
from a
|| connection, but not a receiver, or vice versa.

Make sense.
Thanks

Oct 27 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.