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 10:30:59 +0200
Am Do,21.08.2008 um 08:58 schrieb Oleg Krupnov:
I need to make the design decision regarding how the model and the
views will be kept in sync with each other. Namely:
- I can use key-value coding and observing (KVC and KVO)
- I can use bindings (not sure if it's really different from the KVC/
KVO)
At least it isn't, since a binding registers KVO and uses KVC for data
retrievel.
- I can write the "glue code" myself
The concept of KVC/KVO is new to me. I have been looking at the Sketch
sample (a kind of application I am building myself too), which is
based on KVC/KVO, and I have found that the use of KVC/KVO makes the
program very unreadable and clumsy (like C++ COM code in Windows, you
know), because of the generic messages and hidden dependencies.
There is no "magic". IMHO, it makes the code more readable, beause the
dependencies are not central, but encapsulated.
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:
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?
if you want to have one method per synchronized property, use a
NSString instance as context and simply do that:
// Typed in mail.app, simple example
- observeValueForKeyPath:(NSString*)keyPath ofObject:
(id)observedObject change:(NSDictionary*)change context:(void*)context
{
NSString* updateMethode = [NSString stringWithFormat.@"update%@",
context]; // I didn't care about upper case to keep it simple for
demonstration
SEL selector = NSSelectorFromString( updateMethod );
if( [self respondsToSelector:selector] ) {
[self performSelector:selector];
}
}
This will call a method with the name updateSize, if you set @"size"
as the context at registration.
But: Why?
Cheers,
Amin
than try to fit into the over-generalized
model of KVC/KVO for the sake of skipping a few lines of code. And I
still have to subscribe objects to objects with KVC/KVO, don't I?
Does anyone actually use KVC/KVO? What is your experience? Any
pros/cons, opinions and best practices would be appreciated.
Thanks
_______________________________________________
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
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