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: Erik Buck <email@hidden>
- Date: Thu, 21 Aug 2008 10:54:33 -0700 (PDT)
I love answering questions that require an essay. So here is my essay.
I think my forthcoming Cocoa Design Patterns book does a good job of explaining the patterns used to implement Cocoa and reused to implement Cocoa applications. In particular, the book explains how techniques like Key Value Coding, Key Value Observing, and Core Data are used within the overarching Model View Controller design. However, Key Value Coding and Key Value Observing and Core Data are high level and advanced in part because they are all built upon lower level design patterns. Some people struggle with the basic concepts employed by high level patterns because the lower level patterns are unfamiliar. Other people struggle with the lower level patterns because they dont see the utility of the patterns until they see the high level uses.
KVC
Key Value Coding (KVC) is an implementation of the Associative Storage Pattern. All that means is that you are able to look-up values based on keys (like the way you use NSDictionary). KVC formalizes the idea that every object can be used like a dictionary. NSDictionary provides the objectForKey: and setObject:forKey: methods. KVC extends the NSObject base class to include the valueForKey: and setValue:forKey: methods.
If you follow recommended naming conventions for instance variables and/or Accessor methods, the built-in KVC NSObject versions of valueForKey: and setValue:forKey: access you properties in the form of instance variables or accessor methods automatically. I use the term property because the trick to KVC is that objects represent/store properties in many different ways. Some properties are stored in correctly named instance variables. Other properties are stored in NSDictionary instances. Some properties may be calculated on demand and not stored anywhere. And some properties might be dynamically loaded as needed from an underlying persistent storage like a database or flat file or URL, etc.)
So, in summary, the whole point of KVC is to standardize the way an objects properties are accessed regardless of how they are stored. KVC also provides support (hooks) for change management so that any change to a property can have application defined side effects like registering an undo event or validating the change. KVC provides a way to gracefully handle the situation when a requested property is not available. KVC supports properties that are actually collections like arrays or sets or any other data structure you want within reason.
KVO
Key Value Observing takes advantage of the change management hooks provided by Key Value Coding in order to notify other interested objects whenever an observed property changes. Interested objects register the fact that they are interested. KVO is just another implementation of the Notification pattern also known as the Observer pattern in other frameworks. KVO exists so that you dont have to manually send notifications every time a property changes. This is particularly important because the notification approach only works well when it is ubiquitous. When manually sending notifications, its too easy to forget to send them in a few places and thus greatly degrade the benefits.
KVO is also the basis of Bindings. I would go so far as to say Bindings are just a way to specify which objects observe which properties in which other objects using Interface Builder instead of writing code to register all those notification observers.
Although KVO is built upon KVC, KVO really only needs change notifications. So, if you provide the change notifications, KVO will work even if you dont really use KVC. But why not use KVC ?
Core Data
Core Data is a technology for efficiently storing and accessing a graph data structure of interrelated objects. Efficiency includes memory efficiency as well as persistent storage efficiency. You provide Core Data with information about the objects you plan to store. You tell Core Data what properties your objects have and what constraints and/or initial values the properties have. You tell Core Data about the inter-relationships between your objects. As a result, Core Data can validate the correctness of changes to properties and to relationships between objects.
Core Data uses Key Value Coding. This allows you to access the properties of Core Data objects just like any other objects. This allows Core Data to delay actually loading the values of properties until you ask for the values. This allows Core Data to register undo events each time you change an objects properties or relationships.
If you know XML, you might want to think of Core Data as the combination of a Data Type Definition and the stored data. Core Data uses the Data Type Definition to validate changes made to the data.
Why use Core Data ? Use Core data If you want a flexible high performance self validating graph data structure of application objects that can be interchangeably stored persistently using XML, a fast binary format, or a relational database with automatic undo/redo support and integration with bindings without having to write much code.
Why not use Core Data ? Dont use Core Data if you need to persistently store application data in defined file formats that Core data doesnt support. Dont use Core Data if you have already written your applications model without Core Data.
I have used Core Data for graphics applications. In particular, I have used Core Data to store immense sets of 3D terrain data as well as 3D models, textures, colors, images, and users graphical annotations to terrain. You can create subclasses of Core Datas NSManagedObject class for every type of object you use. I do that so that I can add operations beyond just property access and validation. For example, I might add an animateWaterFlow method to my TerrainScene subclass of NSMnagedObject.
For a 2D vector drawing application, you might have subclasses of NSManagedObject for point, bezier path, color, text, group etc. A bezier path might have relationships to multiple points and one group. A group might have relationships to multiple paths and one optional parent group.
In this essay, I have provided only a sketchy overview. Cocoa Design Patterns is a 300+ page book, so I cant repeat it all here. As I and other have said before, Cocoa is not an al-a-cart framework in most respects. The design patterns are all inter-related and use in combination to provide a total that is more than the sum of the parts. In my opinion, Cocoa is not used effectively until key patterns are understood.
_______________________________________________
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