Re: Listening to bindings
Re: Listening to bindings
- Subject: Re: Listening to bindings
- From: Guy English <email@hidden>
- Date: Fri, 18 Feb 2005 18:51:16 -0500
On Fri, 18 Feb 2005 15:26:10 -0800, Scott Stevenson
<email@hidden> wrote:
> On Feb 18, 2005, at 11:07 AM, Guy English wrote:
> > Clearly, unless there's
> > some wierd and wonderful reason for it, this isn't a good
> > object-oriented design.
> Actually, I disagree somewhat. :)
Ok, well, maybe not "clearly" then. :)
> The dictionary structure isn't the problem and the manual accessors
> don't solve the original problem. If you want to know which individual
> objects were added or removed from an array, you have to use indexed
> accessors:
> <http://developer.apple.com/documentation/Cocoa/Conceptual/
> KeyValueCoding/Concepts/AccessorConventions.html>
That's true if you want the data base to represent the contents of
that array. I suggested the poster implement -init and -dealloc to add
and remove from the DB. Now, obviously, we're talking about two very
different approaches here. Your's is more complex but more flexible
since in my approach every instance of that class is a candidate,
automatically, for serialization to the data base. Now I don't think
that's a terrible idea since in general if you're making a new model
object you want it serialized. But, yeah, I'll admit it may not be
what you want to do.
- (id) init
{
self = [super init];
if ( self == nil ) return nil;
// mark for inclusion in the DB - probably by registering with the
DB controller object
return self;
}
- (void) dealloc
{
// deregister from the DB and have it delete the record
[super dealloc];
}
> As for tracking the individual attribute changes ("subject", for
> example), you have a few options.
> 1. Implement the accessors as you outlined (a perfectly practical
> solution)
[snip - other ways to get it done]
> What I find stylistically displeasing about option #1 is that you can
> end up with a lot of methods that do essentially the same thing. I'd
> rather implement one KVO method that saves changes to the db, but
> that's a personal choice to some degree.
Fair enough. On the other hand having distinct accessors lets you
validate your data without a switch statement. And, yeah, sometimes
it's lame writing all those accessors. You could always get fancy and
catch a message that didn't take in forwardInvocation and handle it by
using the selector name as a key into your dictionary. But that's
pretty fancy.
> > Well I guess the strict "Bad Thing" would be that it evades
> > encapsulation.
> Since everything goes through KVC and is dynmically bound, I don't
> believe this is true.
Well I guess the thing is that not everything in an app *does* go
through the KVO stuff. You're going to write accessors anyway to make
the model object work like one would expect.
> I apologize if some of the examples and explanation in this email are
> unclear, I was trying to keep the size of the post within reason. :)
Yeah, and I'm trying to leave work and get to the pub at quarter to
seven on a Friday night!
Uh ... I should note for those who don't know: Scott develops
DataCrux, which is a great Objective-C to SQLite database framework.
Why he thinks he's qualified to comment on serializing objects like
this though is beyond me. ;)
http://treehouseideas.com/datacrux/
Take it easy,
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