It’s pretty tempting to take a good Cocoa tool—say, Cocoa Bindings—and proceed to use it everywhere, regardless of whether it’s really the best way to solve your problem.
My recent example of this involved Interface Builder.
I wanted to add custom guides to a resizable view, like in this not-for-real example:
Interface Builder is a good Cocoa tool, right? So I used it to set up the little green “knobs”.
Then, I wanted to fiddle with their size.
Hm.
I could, in the above example, manually go in and change the size and location of 8 views in my nib. A disheartening prospect, but Interface Builder is a good tool, right?
But you have to remember why it’s a good tool.
There isn’t really any difference in difficulty between changing a window’s size in Interface Builder and changing it in code. In both cases, you make a change, save, compile, and run.
But Interface Builder is better because you get a mini-preview of the change right there. You can fiddle with it a lot, get it just right, without any compile-run cycle at all. Same with changing a color, or rearranging subviews.
That’s why it’s a good tool. It makes it easy to keep fiddling with the details until you get them just right. If it doesn’t help you with that, then don’t use it.
Once I got that message through my head, I went back to my source code files and wrote an implementation that created and placed the knob views programmatically, based on a single value: knob diameter. (Make your own joke here.) Change that value, compile and run, and see the results instantly. While it cost me an hour or two to make it work like that, after that, it only took me a few minutes of fiddling to come up with a size I liked. And, more importantly, I can go back later and change it again with the same ease. Say, after I’ve run it past a real designer.
Sorry, Interface Builder.
Weaponized Fluff 