Cocoa Bindings - nondebuggable, non-obvious, procedural ???
Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- Subject: Cocoa Bindings - nondebuggable, non-obvious, procedural ???
- From: Izidor Jerebic <email@hidden>
- Date: Mon, 3 Jan 2005 10:16:19 +0100
Hello!
I tried really hard to incorporate bindings in my new application.
Really.
But somehow I couldn't do it. I could not point my finger to the
reason, but it just didn't feel right.
Now that I read Scott Stevenson's remark, that "most developers still
insist on using datasource methods" or something like that, I did some
thinking and came with these reasons why I could not use bindings.
First two are practical, the last and most important is a principled
one:
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
2. Non-obvious
I think that a fairly experienced Cocoa developer should not need to
study manuals to implement Preferences (a couple switches) with
bindings. The GUI in InterfaceBuilder is quite weird, and does not help
you in the least. You need to be the part of inside circle to
understand what you need to type and click to make it work. When it
could be so simple and helping.
This is not a big drawback, but it turned me off the first time I
tried. This could be improved rather easily, though.
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.
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] ;
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...
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.
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