Target–action

The term target–action design paradigm refers to a kind of software architecture, where a computer program is divided into objects which dynamically establish relationships by telling each other which object they should target and what action or message to send to that target when an event occurs. This is especially useful when implementing graphical user interfaces, which are by nature event-driven.

Advantages

The target–action approach to event-driven systems allows far more dynamism when compared to other, more static approaches, such as by subclassing. That is because subclassing is a relatively stiff way to program: a programmer must 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 rebuilt. On the other hand, target-action based programming can change these completely at run-time, thus allowing the program to create new interrelationships and novel behavior 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 Objective-C:

[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.

Disadvantages

Because of the extreme dynamism and freedom of behavior given to programs designed with the target-action paradigm, it can happen that the program designer incorrectly implements a part of the interconnection logic and this can lead to sometimes hard to trace bugs. This is due to the lack of compile-time control provided by the compiler which cannot see the interconnections. Thus interconnection consistency control is left entirely to the programmer.

The result of an incorrectly connected target-action binding can differ based on how the particular system in which the program is implemented regards this:

it can ignore the condition and perform nothing (such as in the button example above – if the target of a button doesn't respond to its action message, pushing the button simply does nothing)
it can consider such a state to be a bug, in which case it will most likely cause the program to crash or invoke a run-time exception

External links

Advantages

Disadvantages

See also

External links