Re: Subclassing Catch-22
Re: Subclassing Catch-22
- Subject: Re: Subclassing Catch-22
- From: Todd Ransom <email@hidden>
- Date: Tue, 26 Apr 2005 16:38:48 -0600
If I augment the return from the superclass, how do I know whether to
call my implementation or super's?
I should have been more clear with this. If I augment the bindingKey...
method, I don't know which class has the logic responsible for adding
the table column.
Todd Ransom
Return Self Software
http://returnself.com
On Apr 26, 2005, at 4:30 PM, Todd Ransom wrote:
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
_______________________________________________
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