I agree that for house keeping not having 22 subclasses would be easy.
There is something about OOP and case statements to decide how to deal
with data ... it just seems more OOPish if the 'system' (in this case
Cocoa Document-Based App (can I say cdba)) picks for me based on a
simple entry in an info.plist.
db
On Jul 26, 2009, at 10:09 PM, Quincey Morris wrote:
On Jul 26, 2009, at 20:39, David Blanton wrote:
I have 22 file types, each with its own C++ methods for extracting
its data.
Now, I could use just one subclass of NSDocument and in the
- (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName
error:(NSError **)outError
method do a case statement on typeName BUT I think it would be
cleaner to subclass NSDocument for each of my file types and
override only the read and write methods.
If the *only* reason for making separate subclasses is the code to
extract the data, I don't see any great advantage. You need 22
pieces of code, and it's probably easier for housekeeping purposes
to keep them all in one place than to spread them around. (But
separate subclasses would be in no way wrong.)
If there are other behavioral differences, then it might make more
sense to use different subclasses.
HTH IMO FWIW
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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/airedale%40tularosa.net
This email sent to aired...@tularosa.net
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
