The combination of Cocoa/Interface Builder would be more rightly termed "message passing" or perhaps "dataflow diagramming" rather than merely object-oriented programming.
Despite some of my "complaint posts", I am doing several significant projects with Cocoa/IB and am exercising the combination thoroughly. Xcode is kind of a bug-ridden, only-a-mama-could-love IDE, but that's another story - a topic for a later day, perhaps.
The strength of Cocoa/IB is in rapid prototyping. During the rapid prototyping phase of a project, you want to write the least amount of code, and get as much functionality or "show me the beef" as possible.
Here I introduce the idea of extending NSControl and NSView derived classes which already conform to the "takeObjectValue" and "takeIntValue" style of messaging protocol. For clarity in this example, I have subclassed both NSSlider and NSTextField to show how adding "forwarding" behavior to your arsenal of visual programming techniques can boost productivity during rapid prototyping. And, if it suits your needs, there is no reason you can't ship code like this.
[[NSApplication sharedApplication] sendAction:[self action] to:[self target] from:sender];
Basically, forwarding controls are simple derivatives of NSControl which, upon receiving a 'take_____ValueFrom' message, both call the superclass implementation, and then perform the action on the target of [self]. This allows a message instigated by the movement of an NSSlider to ripple through the view without any controller/logic code. In the sample, the horizontal slider is the source of the first message. It's action updates the label NSTextField which in turn calls the takeIntValueFrom
message of the rotary slider and so on.
One of my beefs with IB connection logic is that it presents an impoverished view of logic/flow control in an interface. Other variations to consider would be NSControls which offer more than one target/action pair.The Cocoa source code is here