Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Tim Lucas <email@hidden>
- Date: Thu, 6 Jan 2005 12:01:07 +1100
On 06/01/2005, at 9:10 AM, Philippe Mougin wrote:
Here, we are already using the particular conceptual framework of KVC,
since "object attribute" is not a concept that is defined or used by
the OOP theory itself (as opposed as, for instance, the concept of
"object method").
The word "attribute" is synonymous with the word "property" when
discussing OOP theory. I think you may have confused the concept of an
attribute with the concept of an instance variable.
The core foundation of OOP is that an "object" is made up of Properties
and Methods. KVC is directly targeted at object properties.
The following is how KVC technology relates to an Object's properties:
- KVC provides string based access to an object's properties using
'Keys'.
- KVO provides the ability to be notified as to an Object's property's
change in value.
- KVB provides the ability to bind a property of one object to a
property of another.
So how does KVC relate to OO. Let's look at some of the benefits OO
brings to the construction of software:
- Reusability
- Reliability
- Robustness
- Extensibility
- Maintainability
How does KVC affect our OO designs and, hence, which of the above
benefits are affected by using KVC? From my experience KVC encourages:
- Thoroughly designed, simple object models (reusability, reliability,
robustness)
- Less controller code (reliability, maintainability)
- Use of more advanced abstractions, such as the upcoming core data
(extensibility, robustness)
- Unit test friendly model classes (reliability, maintainability)
I fail to see how KVC negates any of the benefits of OOP or goes
against OOP principles.
I think the CocoaDevCentral article (1) on bindings is misleading
people into thinking their objects should be dictionaries, and IMO it
should be revised to eliminate the public NSMutableDictionary's. This
implementation would be unacceptable in all but demonstration
implementations.
Taking the CocoaDevCentral article approach would be fine during a
prototyping phase of a project (less code, easy NSCoding/NSCopying),
but to make the most out of your object model you should definitely be
more explicit and provide tighter encapsulation of your instance
variables.
I use bindings on every application, and I can't remember the last time
I used an NSDictionary.
- tim lucas
http://www.toolmantim.com
(1) Introduction to Cocoa Bindings, CocoaDevCentral.com
http://www.cocoadevcentral.com/articles/000080.php
_______________________________________________
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