 |
This article or section is in need of attention from an expert on the subject. Please help recruit one or improve this article yourself. See the for details. Please consider using {{}} to associate this request with a WikiProject |
Inversion of control - also known as IoC - is a concept, and an associated set of programming techniques, in which the control flow is inverted compared to the traditional interaction model expressed in imperative style by a series of procedure calls. Thus, instead of the programmer specifying, by the means of function calls, a series of events to happen during the lifetime of a programme, they would rather register desired responses to particular happenings, and then let some external entities take over the control over the precise order and set of events to happen. A closely related concept and a direct application of IoC principle is event-driven programming.
Contents |
Example
A practical example to illustrate the precise meaning of inversion in inversion of control would be a simple greeting application that takes the user's name and then continues to display a greeting containing the name. Realised as a basic command-line application, a programme session might look like this:
>> Please enter your name: Wikipe-tan Good day to you, Wikipe-tan!
When realised as a GUI application, the sample could consist of a text field, labelled Name, and a button labelled Greeting, upon the pressing of which the programme would pop up a message dialogue saying Good day to you, <name>!. The important distinction between the above two versions of our greeting programme is how the user interaction happens. In the first case, the flow is always the same: the user first inputs a name, after that the programme displays its greeting and exits. This corresponds in a straightforward manner to the following pseudocode:
def display_greeting(name):
print "Good day to you, " + name + "!"
name = read_name()
display_greeting(name)
exit()
In comparison, in the second case, the user could input a name, then change it to something else before clicking the button, then click it several times in succession without changing the provided name. It could be sketched with the following pseudocode:
def display_greeting(text_field):
name = text_field.read_text()
popup_message("Good day to you, " + name + "!")
button.connect("clicked", display_greeting,
argument=text_field) # connect display_greeting to the "clicked" event
# and pass text_field as an extra argument
wait_for_events() # Loop for indefinite amount of time, waiting for events
Notice how in the first snippet, the control flow is explicitly set by the order of function calls (read_name() etc.). However, in the second case, the programmer only sets up some responses to particular events of interest, and then explicitly gives up the control by calling wait_for_events(), which will enter an infinite loop in which the application will wait for and react to events. The programme will exit when an event happens for which the response set is to exit the waiting loop. Closing the window is usually set as one such event, for instance. The above code illustrates one important aspect of inversion of control: because the programme no longer has direct control over the order of execution of individual functions, some things must change. So display_greeting() no longer is passed a name, as it's not possible to guarantee that the name will be read before the greeting is displayed. Instead, upon registration, an additional argument is passed which will then be passed to display_greeting() each time it is invoked, this argument specifies a location from which the name can be read the moment it's needed.
Advantages and disadvantages of inversion of control
The example, despite its simplicity, hints at some very significant implications of inversion of control. In the straight style, it's immediately obvious what will happen when the programme is run. In return, such a programme is inflexible: if the programmer wanted to allow the user to correct the name before it's submitted, or to display the greeting twice, each such scenario would need to be coded for and supported separately. On the other hand, in the second example, infinitely many possible scenarios can be realised. The price paid for that additional flexibility is greatly increased complexity and the fact that the programme is no longer deterministic: it's no longer possible to tell what functions will be called just by looking at the code; one needs to consider the code and the environment to be able to determine the order of events. The code is also much harder to write and reason about, and computations that are naturally sequential (A needs to happen before B, such as User name must be provided before the login can be successful) can be much harder to write and understand.
Applications of inversion of control
Inversion of control can be applied wherever it's not possible to give a definitive answer to "what does a proper session look like?". Thus, if a programme only has to read some input, perform some computations and produce some output and exit, it's natural to express it in the straightforward style. However, for any long-running programs in which it's not possible to predict the possible course of action, inverted control might be applicable and useful. Examples of such situations include, amongst others, graphical user interfaces, network servers, daemons listening to events from the system/hardware, etc.
See also
- Event-driven programming
- Continuations in Web development
- Dependency inversion principle
- XSL is a data-driven scripting language, meaning that the input data controls which templates (methods) are executed and in what order. Templates automatically return control to the input data upon completion or by using the <xsl:apply-templates /> command.
