Re: OO idiom avoiding switch and if
Jeffrey Oleander wrote: Advice on what's least messy overall or pointers to sources of info would be appreciated. http://en.wikipedia.org/wiki/Finite_state_machine http://en.wikipedia.org/wiki/Reflection_(computer_science) Convert a string matching the symbolic name of a class or function into a reference to or invocation of that class or function. http://en.wikipedia.org/wiki/Type_introspection On the whole, least messy depends on exactly what you're trying to parse. -- GG ___ 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
Re: OO idiom avoiding switch and if
On Thu, Apr 9, 2009 at 9:45 PM, Jeffrey Oleander jgo...@yahoo.com wrote: There's a programming idiom to avoid using complex if statements and switch/case statements, and instead to just send a message to a different class of object. I'm doing some parsing of an old text data format which has a hierarchy with a record and then sub-records and sub-sub records, 1 per line. Each is structured as a type, nesting level number and then various kinds of values depending thereon. What I'm agonizing over is how best to handle invoking the processing for each sub-record type in Objective-C. This would seem to require having a bunch of classes with names like JGRecordTypeParser and then I might do something like: NSString * valueParserClassPrefix = @JG; NSString * valueParserClass = [[valueParserClassPrefix stringByAppendingString:recordSubType] stringByAppendingString:@Parser]; [[NSClassFromString(valueParserClass) alloc] initWithTokens:tokens recordType:recordType level:aLevel]; or some such. In general, a polymorphic approach as in your first example is usually recommended over a switch. It's considered good OOP, and I don't think it's messy at all. In fact, I think that constructing the class name like that is a very elegant use of the dynamic nature of the Objective-C run time. It also follows the Cocoa convention of establishing and using naming patterns. sherm-- -- Cocoa programming in Perl: http://camelbones.sourceforge.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
OO idiom avoiding switch and if
There's a programming idiom to avoid using complex if statements and
switch/case statements, and instead to just send a message to a different class
of object.
I'm doing some parsing of an old text data format which
has a hierarchy with a record and then sub-records and
sub-sub records, 1 per line. Each is structured as
a type, nesting level number and then various kinds of
values depending thereon. What I'm agonizing over is
how best to handle invoking the processing for each
sub-record type in Objective-C. This would seem to
require having a bunch of classes with names like
JGRecordTypeParser and then I might do something like:
NSString * valueParserClassPrefix = @JG;
NSString * valueParserClass = [[valueParserClassPrefix
stringByAppendingString:recordSubType] stringByAppendingString:@Parser];
[[NSClassFromString(valueParserClass) alloc] initWithTokens:tokens
recordType:recordType level:aLevel];
or some such.
Or, I could just do it all in my primary parser class
[self parseValueOfType:recordType subRecordType:subType level:aLevel];
and then have the rat's nest inside there:
switch (recodType)
{
case thisType:
//...
break;
case thatType:
//...
break;
default:
//...
}
Advice on what's least messy overall or pointers
to sources of info would be appreciated.
___
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
Re: OO idiom avoiding switch and if
On Thu, Apr 9, 2009 at 11:20 PM, Sherm Pendley sherm.pend...@gmail.com wrote: On Thu, Apr 9, 2009 at 9:45 PM, Jeffrey Oleander jgo...@yahoo.com wrote: There's a programming idiom to avoid using complex if statements and switch/case statements, and instead to just send a message to a different class of object. I'm doing some parsing of an old text data format which has a hierarchy with a record and then sub-records and sub-sub records, 1 per line. Each is structured as a type, nesting level number and then various kinds of values depending thereon. What I'm agonizing over is how best to handle invoking the processing for each sub-record type in Objective-C. This would seem to require having a bunch of classes with names like JGRecordTypeParser and then I might do something like: NSString * valueParserClassPrefix = @JG; NSString * valueParserClass = [[valueParserClassPrefix stringByAppendingString:recordSubType] stringByAppendingString:@Parser]; [[NSClassFromString(valueParserClass) alloc] initWithTokens:tokens recordType:recordType level:aLevel]; or some such. In general, a polymorphic approach as in your first example is usually recommended over a switch. It's considered good OOP, and I don't think it's messy at all. In fact, I think that constructing the class name like that is a very elegant use of the dynamic nature of the Objective-C run time. It also follows the Cocoa convention of establishing and using naming patterns. A nice intermediate stage between writing a big switch statement and having a bunch of different classes is to use your text to find *methods* rather than classes. For example: NSString *methodName = [NSString stringWithFormat:@proce...@subtypewithtokens:, [[recordSubType lowercaseString] capitalizedString]]; [self performSelector:NSSelectorFromString(methodName) withObject:tokens]; Then you'd write methods named processFooSubTypeWithTokens:, processBarSubTypeWithTokens:, etc. Adding error checking to see if the method exists before you try to call it is also fairly straightforward. If the number of different types isn't too large, this can keep things better organized and more convenient by keeping everything in the same class. Mike ___ 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
