Re: Questions about subclassing IOBluetoothOBEXSession
Re: Questions about subclassing IOBluetoothOBEXSession
- Subject: Re: Questions about subclassing IOBluetoothOBEXSession
- From: Eric Brown <email@hidden>
- Date: Mon, 28 Apr 2003 10:06:30 -0700
On Saturday, April 26, 2003, at 09:00 AM, Paul Davis wrote:
To whom it may concern:
My goal was to subclass IOBluetoothOBEXSession because I needed some
unique
instance variables and methods not contained in this class. There is
one
problem. The class method withIncomingRFCOMMChannel cannot be properly
used
by a subclass because it is defined as:
+ (IOBluetoothOBEXSession *)withIncomingRFCOMMChannel:
(IOBluetoothRFCOMMChannel*) inChannel
eventSelector:(SEL)inEventSelector
selectorTarget:(id)inEventSelectorTarget
refCon:(void *)inUserRefCon;
With this definition, a subclass of IOBluetoothOBEXSession will always
return the IOBluetoothOBEXSession type instead of the subclass type. It
seems to me that the standard objC approach would have been to define
this
class method as follows:
+ (id)withIncomingRFCOMMChannel: (IOBluetoothRFCOMMChannel*) inChannel
eventSelector:(SEL)inEventSelector
selectorTarget:(id)inEventSelectorTarget
refCon:(void *)inUserRefCon
{
id newInstance = [[[self class] alloc] init];
....Do whatever you do to setup an OBEXSession...
return [newInstance autorelease];
}
This way when IOBluetoothOBEXSession is subclassed and the
withIncomingRFCOMMChannel message is received by a subclass, the
instance
returned will be the same type as the subclass.
Do you agree? Of course, I found another way to accomplish what I
wanted to
do. I would have liked my design better if the
withIncomingRFCOMMChannel
method were defined as mentioned.
In theory, the IOBluetoothOBEXSession class encapsulates all of the
necessary public API for an OBEX session. To that end, it shouldn't be
necessary to expose your specific subclass at all. However if you do
add new API, your clients will need to know that they are getting an
instance of your subclass.
Your best bet is to just subclass +withIncomingRFCOMMChannel:... and
then cast the result to the appropriate class. In general, I'm a big
fan of strongly typing return values as much as possible (i.e.
returning IOBluetoothOBEXSession * instead of id). The argument is
that by including the type in the return, the compiler will be much
more likely to catch any programming errors since it knows more about
the object. If we had returned id in that API, all clients would have
had to cast the result to an appropriate type to get the benefit of the
compiler's type checking instead of only the cases where a subclass had
new API to expose. And in the case of +withIncomingRFCOMMChannel:...,
the return type is technically correct since in your subclass, you are
still returning an IOBluetoothOBEXSession *, but is also a member of
your subclass as well. It may even be possible to declare your
+withIncomingRFCOMMChannel:... to return your class rather than
IOBluetoothOBEXSession, although I have not personally tried that
approach. The compiler may complain about not being able to determine
which +withIncomingRFCOMMChannel:... method to use when your client
calls it.
- Eric
_______________________________________________
bluetooth-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/bluetooth-dev
Do not post admin requests to the list. They will be ignored.