• 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: Todd Ransom <email@hidden>
  • Date: Tue, 26 Apr 2005 16:30:41 -0600

If I augment the return from the superclass, how do I know whether to call my implementation or super's?

I also would like to avoid Glenn's solution because there would be so much common code between the methods. Most table columns are added with something like this:

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

	NSString *bindingKey = [identifier lowercaseString];

	[bind...]
}

But many are not as they require formatters, popup cells, etc. For those that are implemented as above I just set them up after none of the conditions in

if ([identifier isEqual: @"Name"]) {

} else if ([identifier isEqual: @"Notes"]) {

[...]

an if statement fail to find a match.

I apologize for not posting the code itself, I deleted it in frustration. I have rewritten it to have the first method return a table column, already bound and with all properties set. This way the logic is not split between two methods. This solved my problem. I guess the larger question, and the reason I only posted pseudo-code in the first place, is there a set of rules or a pattern for knowing when something is safe to subclass? This is the first time I've run into this problem and it is because I failed to consider what would happen when I subclassed during the design phase.

Todd Ransom
Return Self Software
http://returnself.com

On Apr 26, 2005, at 3:54 PM, Ondra Cada wrote:


On 26.4.2005, at 23:45, Marco Scheurer wrote:
On Apr 26, 2005, at 23:17, 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.

Maybe bindingKeyForTableColumnIdentifier in subclasses needs to augment the dictionary of the superclass? That would be easier with a dictionary method you can override:


- (NSDictionary *) keyForIdentifierDictionary
{
NSMutableDictionary *keyForIdentifier = [NSMutableDictionary dictionaryWithObjectsAndKeys...];
[keyForIdentifier addEntriesFromDictionary:[super keyForIdentifierDictionary]];
return keyForIdentifier;
}

Or perhaps even this:

-(NSString*)bindingKeyForTableColumnIdentifier: (NSString *)identifier {
NSString *s=[super bindingKeyForTableColumnIdentifier:identifier];
if (s) return s;
... the original contents ...
}
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc



_______________________________________________ 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
  • Follow-Ups:
    • Re: Subclassing Catch-22
      • From: Marco Scheurer <email@hidden>
    • Re: Subclassing Catch-22
      • From: Ondra Cada <email@hidden>
    • Re: Subclassing Catch-22
      • From: Todd Ransom <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>)
 >Re: Subclassing Catch-22 (From: Marco Scheurer <email@hidden>)
 >Re: Subclassing Catch-22 (From: Ondra Cada <email@hidden>)

  • Prev by Date: Re: ADC Select Membership
  • Next by Date: Re: ADC Select Membership
  • Previous by thread: Re: Subclassing Catch-22
  • Next by thread: Re: Subclassing Catch-22
  • Index(es):
    • Date
    • Thread