• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>)

  • Prev by Date: Re: NaN (Not a Number) Error using Bindings
  • Next by Date: NSTextView replaceCharactersInRange performance and thread safety
  • Previous by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Next by thread: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
  • Index(es):
    • Date
    • Thread