|
Jakarta main
Avalon main
About
Overview
Changes
Download
API Docs
Patterns and Design
Patterns
Reuse Standards
Inversion of Control
Separation of Concerns
Security
The API
What is a Component?
What is a Composer?
The Component Lifecycle
Designing a Component
|
Avalon Developer Documentation
: Patterns
|
Inversion of Control |
One of the key design principles behind Avalon is the principle
of Inversion of Control. Inversion of Control is
a concept promoted by one of the founders of the Avalon project,
Stefano Mazzocchi. The
principle enforces security by design.
It is difficult to track down one paper that defines this pattern
at length, so here are a couple of different definitions of
Inversion of Control.
What it Means |
The Framework plays the role of the main program in coordinating
and sequencing events and application activity.
A designer sets up a chain among objects that can all react
to certain messages in a delegation hierarchy.
Definition by Analogy |
There are a couple of different analogies that make
understanding Inversion of Control easier. We
experience this in many different ways in regular life,
so we are borrowing the form in code. The best analogy,
however, is called "Chain of Command" in the
military.
Chain of Command |
This is probably the clearest parallel to Inversion
of Control. The military provides each new recruit
with the basic things they need to operate at their rank,
and issues commands that recruit must obey. The same
principle applies in code. Each Component is given the
provisions they need to operate by the instantiating
entity (i.e. Commanding Officer in this analogy). The
instantiating entity then acts on that Component how it
needs to act.
|
|
|
How to Apply It |
Inversion of Control is applied in a very simple
manner. Basically, it means that the Component architecture
employs a passive structure. See the following code:
class MyComponent
implements Component, Composer
{
ComponentManager manager;
setComponentManager(ComponentManager manager)
{
this.manager = manager;
}
myMethod()
{
Logger logger =
(Logger)manager.getComponent("com.biz.components.Logger");
logger.log("MyComponent", "Hello World!", Logger.INFO);
}
}
|
The parent of MyComponent instantiates MyComponent, sets the
ComponentManager, and calls myMethod. The Component is not
autonomous, and is given a ComponentManager that has an instance
of the Logger object that is called by role.
The MyComponent class has no state apart from the parent, and
has no way of obtaining a reference to the Logger implementation
without the parent telling it which implementation it can receive.
|
|
| by
Berin Loritsch |
|