*
fe***********@gmail.com:
I'm still learning how to use Object Oriented concepts. I'm have a
basic question dealing with design. I have two classes that deal with
I/O pertaining to network and usb that inherit from an abstract parent
with four basic functions: Open, Read, Write, and Close.
// Note alot of the stuff has been left out
// just to give a basic picture
class IO
{
public:
virtual int Open(..) =0;
virtual int Read(..) =0;
virtual int Write(..) =0;
virtual int Close(..)=0;
};
class network : public IO{
....
};
class usb: public IO {
...
};
Now I want to create a class that uses the network or usb to
read/write. The different ways of doing these and I'm not sure which is
appropriate. Here my inital thoughts
1)
class MyProtocol
{
IO* m_io;
public:
MyProtocol(IO *);
};
Here I could give my class MyProtocol either Network or Usb and it
wouldn't care. The other choice
2)
class MyNetworkProtocol: public Network
{};
class MyUsbProtocol: public Usb
{ };
Here I will create two classes for each one but each class would have
the same logic.
Assuming that the same protocol _may_ be used with both 'network' and 'usb'
choice 2 would mean redundant code, which is nearly always Evil (e.g., think
of maintenance, keeping two corresponding implementations in synch).
Also, the inheritance should probably not be public, because a protocol
isn't an 'io': you wouldn't want client code to circumvent the protocol,
calling 'read' and 'write' directly, would you?
However, you could do something like choice 2 as
3)
template< class IoProvider >
class Protocol: private IoProvider
{
...
};
The difference between choices 1 and 3 is that 1 provides _run-time_
selection of the IoProvider, while 3 provides _compile-time_ selection.
Choice 1 is far more flexible. While choice 3 can help you avoid things
like using an inappropriate Protocol/IoProvider combination, catching such
errors at compile time (e.g. a partial specialization with no
implementation) I don't think that's very much of an advantage in practice.
Also, choice 3 is more difficult to implement and debug.
These are the two choices that I thought of but I'm not sure which one
is appropriate. I'm still unsure about the design, I'm open to any
advice. Thanks
It may be that also Protocol should be designed as a pluggable class. And
perhaps it might be a good idea to think about protocol stacks, i.e.
protocols plugged into protocols for a few levels. But whether you need
that depends on the application you have in mind, and since generality
nearly always has some cost, both in development time and run-time, it is a
matter of biting nails, throwing dice, soliciting advice, perusing budgets,
checking what others have done, and so on, so as not to overdo generality.
Final word of advice: think about whether Protocol should be directly used
by client code.
Perhaps the design will be a lot cleaner if Protocol is designed as
pluggable into some class X that has a public interface adapted exclusively
to the client code's needs (implementing X might help design Protocol)?
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
