The target-action approach to event-driven systems allows for a much greater deal of dynamism when compared to other, more static approaches, such as by subclassing. That is because subclassing is a relatively stiff way of programming - the programmer has to lay out the internal interconnection logic of a program at design time and this cannot be changed later (unless the program is stopped, reengineered and built again). On the other hand, target-action based programming can change these completely at run-time, thus allowing the program to create new inter-relationships and completely novel behavior all by itself.
A prime example of this approach is the OpenStep API, which partly thanks to being based on the dynamic Objective-C language, has much of its graphical user interface implemented by using the target-action paradigm. Consider the following example (written in the Objective-C language):
[button setTarget: self];[button setAction: @selector(doSomething)];
Now when the button identified by the button variable is pressed, the runtime system will try to send a message named doSomething to the object in which this code has been invoked. It is also very well possible to determine the message to be sent at run-time:
[button setTarget: self];[button setAction: NSSelectorFromString([textField stringValue])];
Here the message which is to be sent is determined by consulting a text field's string value (the string of text which the user typed into a text field). This string is afterwards converted into a message (using the NSSelectorFromString function) and passed to the button as its action. This is possible because, under Objective-C, methods are represented by a selector, a simple string describing the method to be called. When a message is sent, the selector is sent into the ObjC runtime, matched against a list of available methods, and the method's implementation is called. The implementation of the method is looked up at runtime, not compile time.
