Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Re: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: mmalcolm crawford <email@hidden>
- Date: Mon, 3 Jan 2005 13:40:35 -0800
On Jan 3, 2005, at 1:24 PM, Izidor Jerebic wrote:
- (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)
Then it sounds as if you're violating your own rule by not adhering to
the principle of encapsulation within the existing add: method? (I.e.
you're changing the instance variable value directly rather than
through accessor methods.)
If you want to change the instance variable directly, however, you are
free to do so, provided that you add two, very simple, method calls
before and after the change is made.
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.
This should not be more work, if you're adhering to normal Cocoa coding
standards and using encapsulation -- you should be calling those
accessor methods anyway...
Moreover, you're only looking at one side of the equation. It may well
be the case that ensuring KVC, or in particular KVO, compliance
requires some additional effort (although typically this will be very
simple). However, in most cases this is likely to be outweighed by
savings elsewhere (ensuring UI consistency by writing your own glue
code can be very complicated, and much more fragile). In some cases it
will not. As has been stressed on many occasions, bindings is simply
another tool in your coding chest -- it is not necessarily the best
tool to use in all circumstances.
mmalc
_______________________________________________
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>) |