• 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: Subclassing Catch-22
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Subclassing Catch-22


  • Subject: Re: Subclassing Catch-22
  • From: glenn andreas <email@hidden>
  • Date: Tue, 26 Apr 2005 16:57:57 -0500


On Apr 26, 2005, at 4:17 PM, Todd Ransom wrote:

The code looks like this:

- (NSString *)bindingKeyForTableColumnIdentifier: (NSString *)identifier {

NSArray *keys = [NSArray arrayWithObjects: @"name", @"notes", @"status", nil];
NSArray *identifiers = [NSArray arrayWithObjects: @"Name", @"Notes", @"Status", nil];


NSDictionary *keyForIdentifier = [dictionaryWithObjects: keys forKeys: identifiers;

	return [keyForIdentifier valueForKey: identifier];
}

- (BOOL) tableViewAddColumnWithIdentifier: (NSString *)identifier {

NSString *bindingKey = [self bindingKeyForTableColumnIdentifier: identifier];

	[create a table column, bind it, add it to a table]

}

The theory was that subclasses would override both methods, returning the appropriate key to bind to and implementing whatever specifics were required for the table column (popup button cells, date formatters, etc.).

It all worked fine except I wanted the subclasses to defer to super for columns shared by all views.



How about taking advantage of some of the flexibility of the underlying runtime?

@implementation CommonSuperclass
- (BOOL) tableViewAddColumnWithIdentifierName
{
// whatever name does
}
- (BOOL) tableViewAddColumnWithIdentifierNotes
{
// whatever notes does
}
- (BOOL) tableViewAddColumnWithIdentifierStatus
{
// whatever status does
}
- (BOOL) tableViewAddColumnWithIdentifier: (NSString *)identifier
{
SEL selector = NSSelectorFromString([NSString stringWithFormat: @"tableViewAddColumWithIdentifier%@", identifier]);
NSMethodSignature *signature = [self methodSignatureForSelector: selector];
if (!signature) {
// we don't support this identifier
return NO;
}
NSInvocation *invocation = [NSInvocation invocationWithMethodSignature: signature];
[invocation setSelector: selector];
[invocation invokeWithTarget: self];
// find out if the routine had any problems by getting it's return value
BOOL retval;
[invocation getReturnValue: &retval];
return retval;
}
@end


@implementation ASubclass
-  (BOOL) tableViewAddColumnWithIdentifierAddress
{
	// do whatever the special subclass that supports address does
}
@end


You could also use the simpler "performSelector" but since it technically is for selectors that return an id, it's poor practice to use it to return a BOOL (plus using an invocation lets you specify whatever additional parameters you need).






Glenn Andreas                      email@hidden 
 <http://www.gandreas.com/> oh my!
quadrium | build, mutate, evolve | images, textures, backgrounds, art

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Subclassing Catch-22 (From: Todd Ransom <email@hidden>)
 >Re: Subclassing Catch-22 (From: Marco Scheurer <email@hidden>)
 >Re: Subclassing Catch-22 (From: Todd Ransom <email@hidden>)
 >Re: Subclassing Catch-22 (From: Greg Titus <email@hidden>)
 >Re: Subclassing Catch-22 (From: Todd Ransom <email@hidden>)

  • Prev by Date: Re: Subclassing Catch-22
  • Next by Date: Limiting Character Input In An NSTextField
  • Previous by thread: Re: Subclassing Catch-22
  • Next by thread: Re: Subclassing Catch-22
  • Index(es):
    • Date
    • Thread