Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Charlton Wilbur <email@hidden>
- Date: Tue, 4 Jan 2005 13:56:51 -0500
On Jan 4, 2005, at 12:33 PM, Izidor Jerebic wrote:
The below excerpt is the best I could come up with. If your object
model does not fit naturally with KVC/KVO (typically objects with
complex behaviour do not fit), it does not make sense forcing it.
Objects with complex behavior can fit perfectly well. The question is
whether it is useful for the object to publish a set of key-value pairs
and send notifications when they change, and I can't think of any
situations where neither would be useful. I can understand that
sometimes it would not be meaningful for an object to publish some
information, but not that it's too difficult, in cases where it is
meaningful for an object to publish this information or send
notifications, to implement key-value coding or key-value observing.
"Complex behavior" is a red herring. Even objects that have extremely
complex behavior have accessor methods, and KVC is an alternate
approach to accessor methods. Sometimes derived values change,
especially in complex objects, and if that change needs to be
propagated to somewhere else -- another object, the GUI -- then you
really have two choices: the other object that needs to know the value
can poll the complex object periodically and note for itself if the
value has changed, or the complex object can post a notification that
the value has changed. KVO offers a rather simple, well-supported way
to notify interested objects that that value has changed -- something
you'd need to do anyway.
It might be better to write all view-related code (basically code that
would be needed for KVO/KVC) in separate Controller classes, and not
in Model classes.
But KVO/KVC is also useful in the model! Example: I have an
application that manages a network of objects that are largely
interdependent. When one of the inputs to one of the objects changes
(most often because of user input), that change needs to propagate
throughout the object graph. So each object has a method that
recalculates its outputs based on its inputs, and posts appropriate
notifications for the ones that have changed. When the container adds
an object, that object uses KVO to keep track of its inputs. All of
this happens in the model.
Now, if I were for some reason forbidden to use KVC/KVO, I'd still have
to have that method to recalculate the outputs, and I'd still have to
notify all the objects interested in the object's outputs. (Well, I
*could* just iterate through all the objects and recalculate all of
them periodically, but that's extremely inefficient when a change in
one object's output may only need to propagate to 2 or 3 other
objects.) The difference is that I'd have to do it manually, which
would mean I'd have a couple hundred more lines of code to maintain -
and I'd have a lot more complicated logic involved in adding objects to
the network and removing them. A dozen lines of fairly straightforward
code in the class itself, or a couple hundred lines of complex and
bug-prone code in an object's controller class -- I know which one I'd
prefer. And all of this is *before* we get out of the Model layer!
Charlton
--
Charlton Wilbur
email@hidden
email@hidden
_______________________________________________
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
| References: | |
| | >Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Tim Lucas <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Charlton Wilbur <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: mmalcolm crawford <email@hidden>) |
| | >Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ??? (From: Izidor Jerebic <email@hidden>) |