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: Mon, 3 Jan 2005 23:01:30 +1100
Izidor,
On 03/01/2005, at 8:16 PM, Izidor Jerebic wrote:
1. Non-debuggable
Once you use bindings, and program does not behave as it should, you
can only slaughter chicken or goats and dance and pray to the
all-mighty god of Cocoa to help you. There is no tool to help you see
what is and is not happening. This is a major drawback
This is annoying I agree, but there is help. Check out GandBug at
http://projects.gandreas.com/gandbug/ . Its does runtime debugging of
Cocoa bindings.
3. Procedural thinking - objects as structs
This is the major one, and the most problematic. Cocoa Bindings'
mental model is of objects as passive lumps of data. It shows its
inheritance from EOAssociation and the way it is most correctly used,
but nevertheless, it is quite dangerous, because it forces a developer
to create the application object model in a very non-OO way, if it is
to work nicely with bindings. Bindings are really well suited to
extremely simple objects - a C structs with set/get methods (which
actually are not objects in proper OO sense - those contain behaviour
and data). Anything else makes the developer write additional code to
make objects look like this.
You've lost me with the C structs comment. How is it less OO? All
participants in binding are either messages, objects or object proxies.
And if a developer is just starting with Cocoa, this non-OO way of
thinking will subconsciously make his object modelling very wrong,
indeed. As an example, lets assume we have a calculator object, which
can perform operations (lets say that calculator holds the operations
as stack, so you can get a paper trail, so nothing as 'value' variable
exists inside of object). There are two ways to implement adding.
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"];
}
IMHO, the first approach is the correct one. But if you want to use
bindings, you will need to write additional code for set/get. The
second one (procedural, not object-oriented) will get you bindings
working for free. No new code. So if you subconsciously learn this,
your code will steadily become procedural and not object-oriented.
In conclusion, I think that bindings are great for preferences (I did
manage to implement them with bindings) and data-oriented parts of
applications (inspectors, data-entry). Bindings will probably become
extremely useful with CoreData, as its predecessors were.
But they are not suitable for general development, and can be really
harmful to proper object-oriented modelling, if applied
indiscriminately...=
Anything applied indiscriminately to anything can be harmful. How about
outlining the situations you think it would be harmful to apply Cocoa
bindings?
I would like to be corrected and I really welcome any response that
would do something to point out the mistakes I made in my thinking.
Especially any positive experiences and examples. I do not want to
miss any benefits.
I can testify the research staff, teaching staff and students of my uni
(UNSW) have found bindings to be extremely effective and have never had
to sacrifice object modelling to ensure KVC compliance (except for
maybe adding some extra code). Personally I have found Cocoa bindings
to encourage better object designs (for example using a Window
Controller for each window and binding through File's Owner).
- tim lucas
_______________________________________________
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