Target-Action
From Wikipedia, the free encyclopedia
The term Target-Action design paradigm refers to a kind of software architecture, where a computer program is divided up 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.
Contents |
[edit] Advantages
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.
[edit] Disadvantages
Because of the extreme dynamism and freedom of behavior given to programs designed with the target-action paradigm in mind, it can happen that the program designer incorrectly implements a part of the inter-connection logic and this can lead to sometimes difficult to trace bugs. This is due to the lack of compile-time control provided by the compiler which cannot see the inter-connections. Thus inter-connection consistency control is left entirely up 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
[edit] See also
- The OpenStep API
- Objective-C
