Re: Design Question: Pro & Cons of KVC/KVO
Re: Design Question: Pro & Cons of KVC/KVO
- Subject: Re: Design Question: Pro & Cons of KVC/KVO
- From: Negm-Awad Amin <email@hidden>
- Date: Thu, 21 Aug 2008 15:48:13 +0200
Am Do,21.08.2008 um 15:22 schrieb Oleg Krupnov:
I suspect that it could be way easier, when a property's value
changes, to just explicitly send a concise and clearly named message
to the subscribed objects,
This is, what is done. The name of the message is
-observeValueForKeyPath:ofObject:change:context:
Then how is it better than manual "glue code"?
1. You do not have to manage a list of observes. this is done by cocoa.
2. cocoas implementation is faster than everything you would program.
3. Less Coding for you
4. Compliance with cocoa concepts
Enough?
I think, you want to say, that if one changes a property, he sends
a message
to a central MVC server, which distributes update messages.
Correct? Why?
No. Actually, the alternative approach that I kept in mind was that
each model object maintains an array of observers (like delegates or
just objects with a declared protocol) to all of which the
corresponding message is sent each time a property of the model object
changes.
Sounds like KVO.
For example,
id<MyModelObjectObserver> observer;
MyModelObject* myModelObject;
// subscribe observer
[myModelObject addObserver: observer];
// set some prop
[myModelObject setSomeProp:someValue];
@interface MyModelObject
{
NSMutableArray* m_observers;
id m_someProp;
}
@end
@implementation MyModelObject
- (void)addObserver:(id<MyModelObjectObserver>) observer
{
[m_observers addObject:observer];
}
- (void)setSomeProp:(id)newValue
{
// save new value
m_someProp = newValue;
// notify observers
id<MyModelObjectObserver> observer = nil;
for (observer in m_observers)
{
[observer somePropChanged];
}
}
@end
Looks like a bad implementation oif KVO.
What is the advantage of reprogramming KVO?
Beside this: Do you want to use core data? What about core data
properties?
Is there something terribly wrong with this approach?
There is nothing wrong in programming a new string class. But why
don't you use NSString?
The dependencies
are encapsulated. In addition, it seems that this approach gives me
more flexibility, say, if newValue is invalid, it can be rejected.
Key value valdidation
Or,
for instance, when the entire MyModelObject gets removed from its
parent model object - in this case there is no property actually
modified, instead, a mutator message is received by the model, but the
observers still need to be notified. Can KVC/KVO monitor the contents
of an array of model objects?
Of course. Look at the array controller.
And so on. Even though KVC/KVO may
handle these cases too, my intuition tells me there can be cases when
the flexibility of KVC/KVO may run short compared to the manual code.
My intuition is, that you don't want to get deeper with KVO und KVC
and are searching for reasons to reject it.
Anyway, even if I assume that KVC/KVO is at least not worse than
manual code, I don't see any real benefit so far. Except that it
allows me to get the scripting support "for free" (but I'd rather like
the scripting to be separate thing and not get in the way of the model
objects).
Could someone please try to explain me the rationale behind KVC/KVO
once again? :) Thanks
In five minutes?
You want to hold an oberserver list for every property and every
object. This is done by KVO. And ist is done for KVC with Core Data.
And it works with bindings. And it is implemented very good through
isa-swizzling. And And And …
There is nothing wrong in writing a Cocoa II.
But: Why?
Cheers,
Amin Negm-Awad
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden