On Thu, Nov 4, 2010 at 9:12 AM, Jonny Taylor <[email protected]> wrote:
>>> One workaround is to include explicit casts like I have shown. However this
>>> leaves me wondering whether it goes against convention and/or
>>> recommendations to have two init methods with the same name but different
>>> parameter types, even for two unrelated different classes (hard to enforce
>>> - one could imagine completely different codebases colliding by chance in
>>> this respect). Can anybody comment on this?
>>
>> One question that comes to my mind is whether, given the similarity in
>> their names, are your two camera classes really *entirely* unrelated?
>> Is there a common base class, or a protocol they could share? Could
>> they be made into a class cluster? If so, you could declare your init
>> like one of these:
>>
>> -(id)initForCamera:(CameraBase*)cam;
>> -(id)initForCamera:(id<CameraProtocol>)cam;
>
> You are right on the mark there - I do in fact have a CameraProtocol defined.
> However in this case the classes that are being inited are "frame" classes
> QIFrame and PSFrame. These classes (and only these classes) need to
> understand the implementation details of individual camera models, and their
> implementation is a lot simpler if they have access to a pointer to the
> actual camera subclass.
Maybe a class cluster then, with a base Frame class whose
-initForCamera: chooses which subclass to return. To avoid a lengthy
switch statement, the CameraProtocol could include a -frameClass
method that returns the Class that's appropriate for that camera
subclass:
- (id)initForCamera:(id<CameraProtocol>)cam {
[self release];
self = [[cam frameClass] alloc] initForCamera:cam];
return self;
}
The idea here is similar to that of Cocoa's string and collection
classes, where users don't need to know or care which specific
subclass any given instance belongs to.
sherm--
--
Cocoa programming in Perl:
http://camelbones.sourceforge.net
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
