Re: Convenience Methods
Re: Convenience Methods
- Subject: Re: Convenience Methods
- From: Uli Kusterer <email@hidden>
- Date: Thu, 27 Sep 2007 09:58:40 +0200
Am 27.09.2007 um 01:37 schrieb Jeff Laing:
Now, in this case, you can call
Dog *pet = [Dog animalWithName:@"Rover"];
but that feel uncomfortable to me. I'd still be inclined to add
another
method so I could write:
Dog *pet = [Dog dogWithName:@"Rover"];
even if all it did was wrap up the same methods.
One advantage of going with the "uncomfortable" variant is that you
can have generic creation code. E.g. if you have plug-ins that
contain new animals, you can do:
Animal* foodSource = [[myBundle principalClass] animalWithName:
[nameField stringValue]];
Yes, this code could make you eat a dog, but then that's the whole
point of polymorphism: As long as it is an animal, you treat it the
same. Even better, you can load each plugin, add its principalClass
to an array or dictionary, and then use the index or key to create a
new object of these types based on user data, e.g. a popup selection.
Another advantage is that you don't needlessly pollute the
namespace with additional methods or introduce additional code paths.
If you work with another programmer, that programmer may not be aware
that animalWithName: exists if you provide a dogWithName:, and may
not bother to search upwards in the class hierarchy. He'll override
dogWithName to do some additional work (even if it's just debug
output), and it'll work for all but those 10% of your dogs that
someone creates through class pointers and animalWithName:.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
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