Re: Listening to bindings
Re: Listening to bindings
- Subject: Re: Listening to bindings
- From: Guy English <email@hidden>
- Date: Fri, 18 Feb 2005 14:07:24 -0500
Hi,
On Fri, 18 Feb 2005 11:09:30 -0700, Jiva DeVoe <email@hidden> wrote:
> Just out of curiosity, why not use NSDictionaries (or model classes
> with NSDictionaries to hold their properties) for models?
> The reason I ask is I saw an example that did exactly this
> (http://www.cocoadevcentral.com/articles/000080.php) and they seemed to
> suggest it was a good way to encapsulate a lot of fields within an
> object.
Well, first, that's a great article. Scott did a terrific job
explaining how things work and it's a really good looking page to
boot. The one critique, and I'm sure he's aware of it because it's
come up here before, is that the model objects break encapsulation.
The problem isn't so much in using an NSDictionary in a pimpl-esque
pattern. The problem is in exposing the object properties
"un-shielded":
@interface Email : NSObject
{
NSMutableDictionary * properties;
}
- (NSMutableDictionary *) properties;
- (void) setProperties: (NSDictionary *)newProperties;
@end
Now, in the bindings he'll binds to "properties.subject". That's all
well and good and it works fine. The problem is that you haven't had
to go through an accessor to change a value in the object. You've got
the emails properties then changed an attribute but the email has no
way to know about it.
I mentioned it being a bad idea in the original post because the
question was about tracking changes to a model. He wanted to detect
updates, inserts and deletes. The approach he was considering was
"listening to bindings" or snooping the communication so he could
update his underlying data base correctly. Clearly, unless there's
some wierd and wonderful reason for it, this isn't a good
object-oriented design.
Consider:
@interface Email : NSObject
{
NSMutableDictionary * properties;
}
- (void) setSubject: (NSString*) subject
- (NSString*) subject;
@end
@implementation Email
- (void) setSubject: (NSString*) subject
{
[properties setObject: subject forKey: @"EmailSubject"];
}
- (NSString*) subject
{
return [properties objectForKey: @"EmailSubject"];
}
@end
This model still uses the dictionary in a pimpl style pattern but has
accessors so it's much easer to track dependent state - like knowing
to update your database. With this you'd bind to simply "subject" not
"properties.subject".
> [snip] in practice it
> *does* seem very nice and very simple... particularly when working with
> bindings which, in some cases, can allow you to add properties to your
> objects without changing any code at all this way.
Yes, it's great for prototyping or maybe even some trivially simple
object. It's also pretty good as a way to explain bindings since it
reduces the amount of code and you can focus on what's going on with
IB. Unfortunately, it doesn't scale too well and, with Scotts article
being such a popular tutorial, has a tendency to be used where it
shouldn't be.
> So I am curious, from an analysis standpoint, what are your reasons for
> saying it's a "Bad thing"? (Not saying it isn't, but am trying to
> figure it out myself).
Well I guess the strict "Bad Thing" would be that it evades
encapsulation. I'm not an OO bigot enough to think that there's never
a place for that kind of thing but when you start looking for wierd
hacks to listen to bindings being triggered it's time to re-think the
situation. That said, we haven't heard back from the original poster
so maybe he does have a good reason to be doing what he wants to do.
Take care,
Guy
_______________________________________________
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