• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: OO idiom avoiding switch and if
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OO idiom avoiding switch and if


  • Subject: Re: OO idiom avoiding switch and if
  • From: Michael Ash <email@hidden>
  • Date: Fri, 10 Apr 2009 00:41:32 -0400

On Thu, Apr 9, 2009 at 11:20 PM, Sherm Pendley <email@hidden> wrote:
> On Thu, Apr 9, 2009 at 9:45 PM, Jeffrey Oleander <email@hidden> 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:@"process%@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 (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

References: 
 >OO idiom avoiding switch and if (From: Jeffrey Oleander <email@hidden>)
 >Re: OO idiom avoiding switch and if (From: Sherm Pendley <email@hidden>)

  • Prev by Date: Re: Change view on resize
  • Next by Date: Re: Setting Min, MAx and range of characters for NSTextField
  • Previous by thread: Re: OO idiom avoiding switch and if
  • Next by thread: Re: OO idiom avoiding switch and if
  • Index(es):
    • Date
    • Thread