On Tue, Oct 7, 2008 at 9:31 AM, Karan, Cem (Civ, ARL/CISD) <[EMAIL PROTECTED]> wrote:
> My dilemma is how to do this hookup; I can use either notifications or > bindings, but I can't decide which is better in this situation. Bindings > seem to be simpler to use, but reading about them suggests that you are > expected to use the MVC design pattern, and I'm not doing MVC here. > Notifications are used anywhere you want, but require more (and more careful) > work to get right. So, are bindings considered general purpose, or should > they really be reserved for MVC situations (even though they can work > anywhere)? This is hard to answer in the abstract but in an attempt to color your thinking... KVO is about making _properties_ of an object observable. For example did the name of person object change or the current mode of a I/O connection object change. It gives you the ability to observe at the granularity of a property of an object (including a hierarchy of object using key-paths). Additionally once you support KVO then you can leverage the controller layer (bindings) to wire up UI, etc. directly to properties of your objects (including a hierarchy of object using key-paths). Notifications are a generic decoupled notification system that allows observers to listen for specific notifications (by name) possibly from specific objects, etc. These typically are more about something happening and less about a property of an object changing (however the later can be considered a special case of the former). You get "better" granularity for "free" with KVO but with a cost of having one funnel point (observeValueForKeyPath:ofObject:change:context:) into the observer unless you decide to use KVB (bindings) to bind a property of the observed object to a property of observing object. Also support for key paths and dependent keys can be a win depending on what you need. You get "better" arbitrary notification ability using notifications and the ability to coalesce, etc. if you utilize your own notification queues. Also you get to specify the entry point (selector) into your observer when can result in cleaner code. -Shawn _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
