Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Izidor Jerebic <email@hidden>
- Date: Mon, 3 Jan 2005 22:24:34 +0100
On Jan 3, 2005, at 7:36 PM, mmalcolm crawford wrote:
On Jan 3, 2005, at 4:44 AM, Izidor Jerebic wrote:
First:
[calculator add:someNumber] ;
Second:
val = [calculator value] ;
newVal = val + someNumber ;
[calculator setValue:newVal] ;
What you've done has completely lost the encapsulation of the 'add'
method to the calculator object.
You can still use [calculator add:someNumber], but inside the 'add'
method you would do:
- (void) add:(float)addition
{
float newValue = [self value] + addition;
[self setValue:newValue forKey:@"value"];
}
Exactly. What I have done in the [second] example is really wrong.
But, as you can see, it is easier to get bindings working that way.
So if you write bad, un-encapsulated code, it is easier to use
bindings. This is the harm I was talking about.
It's not clear what is wrong with Tim's suggestion. If you implement
add: as he proposes, then your first example works as required.
The problem arises when the add: method is already implemented and is
quite well behaving for purposes of addition (encapsulation), but is
not the one Tim suggested. There is no need for the add: method to be
like the one above. It might do any sorts of things internally. And it
is quite correct to be able to do it, because these things are internal
to the object, and can be implemented independently of the environment.
And, besides that, with bindings you need to spend extra effort,
because there are more demands on your code - one is the basic model
behaviour, and the second is bindings (KVO/KVC).
In the example above you have actually created a second layer of
abstraction above KVC/KVO - all the behaviour (add:) is implemented via
KVC methods. Instead of a single layer (object's methods) now you need
two - object's methods (its interface to the external world) and below
it KVC/KVO primitives. If this is not more work, I do not know what is.
The only case when this does not happen is with simple objects - ones
with little or no behaviour, where KVC/KVO layer becomes also object's
interface layer. These are the C structs with get/set methods I was
talking about.
And if you skimp on time/effort and focus only on bindings part, you
end up with non-encapsulated objects, which have only KVO/KVC layer,
without behaviour layer. This is the harm done with beginners, which
might use bindings with bad design, since it is the path of least
effort (and we all know we try to use our strength economically)...
I am not trying to put down the idea of bindings. I am using
willChange/didChange internally in all my apps (kind of homegrown
KVC/KVO). I just cannot see the benefits of Cocoa implementation being
used in general application with complex object model (meaning complex
behaviour), compared with the costs...
izidor
_______________________________________________
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