Re: Can a subclass of NSDictionary do this?
Re: Can a subclass of NSDictionary do this?
- Subject: Re: Can a subclass of NSDictionary do this?
- From: Marco Scheurer <email@hidden>
- Date: Thu, 24 Jul 2003 23:53:09 +0200
On Thursday, July 24, 2003, at 11:12 PM, James Quick wrote:
On Thursday, July 24, 2003, at 04:48 PM, James Quick wrote:
On Wednesday, July 23, 2003, at 01:36 PM, Marco Scheurer wrote:
And IMHO, using key paths of length > 1 is usually not such a good
idea. Of course it's handy, but it breaks encapsulation. Better to
ask directly valueForKey "c" and let the receiver figure out how to
get > it.
Could you elaborate? It would seem to me that an abbreviated key
would obfuscate the
intention of the original writer. He's obviously intending his
lookup to produce a result.
What benefit offsets the cost of maintaining code that less clearly
states its purpose to the reader?
My questions were poorly chosen. I was confusing length of key path
with length of the
keys, and was trying to figure out why you thought looking for an
abbreviation is better.
oops.
I still disagree with your contention that longer key paths, are a bad
idea.
Asking for the value c may be a good choice in the case where names
within a
level are globally unique. In other contexts common names occurring
in each of
multiple subpaths, reflect a hierarchical order of common attributes
for different
enclosing objects.
Exporting the complexity of the search exposes more detail to the
consumer
which is irrelevant to his goals. He is given a key and needs to bind
it a value.
Delegating the details of the lookup to the storage medium seems like
a better
example of making use of encapsulation, hardly an act of breaking it.
It hides
the implementation detail from the user.
Yes, I understand that you don't like the fact that such a lookup
makes an implicit
assumption about the receiver and the types of it's contained objects,
e.g. that 'b'
is expected to be an instance of a Dictionary. I don't however see
that exporting
the lookup logic to the consumer is preferable.
I'll use messages, but the reasoning is the same with key paths. The
problem is breaking encapsulation and revealing too much about the
implementation: the whole object graph or other implementation details.
For instance, you can often see access methods such as these:
@interface Company : Object
{...
}
- (NSArray *) employees;
...
@end
This can be used like this:
int headCount = [[myCompany employees] count]; // or [myCompany
valueForKeyPath:@"employees.count"]
If you decide to change the implementation of Company (because you want
another type of collection, or you want to introduce departments and
groups, or you want to include consultants in the head count), your
client code breaks, unless you reimplement -employees.
The alternative is to add to Company the accessor methods needed to
access, iterate, look for employees:
@interface Company : Object
{...
}
- (unsigned int) headCount;
- (void) makeEmployeesPerformSelector:(SEL) aSelector;
- (BOOL) isIncludingEmployee:(Employee *) anEmployee;
...
@end
I know this is controversial, and that it can require a bunch of
(trivial) methods. This is also not encouraged by tools like EOF or
WebObjects, and I'm also not always doing this, but when I do, I
usually don't regret it.
But the initial suggestion, that takeValue:forKeyPath: should create
intermediate objects is even worse. It seems to me that it is the
equivalent of the following:
@interface Company : Object
{...
}
- (NSMutableArray *) employees;
...
@end
where the client is free to add and remove employees, bypassing the
logic that could be implemented in the proper accessor methods;
- (void) addEmployee:(Employee *) anEmployee; // or
addToEmployees...
- (void) removeEmployee:(Employee *) anEmployee; // or
removeFromEmployees...
I'm pretty sure that nobody will find controversial that exporting a
mutable array instead is a bad thing.
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.