Re: init method ambiguity
Re: init method ambiguity
- Subject: Re: init method ambiguity
- From: Sherm Pendley <email@hidden>
- Date: Thu, 4 Nov 2010 12:17:36 -0400
On Thu, Nov 4, 2010 at 9:12 AM, Jonny Taylor <email@hidden> 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@hidden)
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:
This email sent to email@hidden