|
Jakarta main
Avalon main
About
Patterns and Design
The API
|
Avalon Design Documentation
Avalon Design Documentation
|
How is the Component Going to be Used? |
The first step in writing the Component is determining how it is going
to be used. There will be a number of times where you have a powerful
Component that can be used in many different contexts. Those contexts
may include executing the Component from the command line (separate
from Avalon), using it as a part of a sub system, or using it as an
integral part of Avalon.
Part of Avalon |
All Components are an integral part of Avalon, so there is really
nothing to be done beyond specifying its interface (role). It is
important to identify and document it's social contract with the
rest of the system. What I mean by social contract is the order
of dependencies, what it needs to function, and what it supplies
to the rest of the system.
|
Part of a Sub System |
A sub system can either be part of Avalon, or live in a separate
context. A perfect example would be a Component that can function
within a Servlet or Enterprise Application. Neither of those
contexts are native to Avalon (though they can easily be built
on top of Avalon).
It is important to do even more careful planning than in the
first scenario. The reason is that you want the interface to be
as generic as possible and still accurately represent its role.
Because the contexts that may not be an integral part of Avalon,
you must take care to use the Component in the same manner as
Avalon would. That means that you follow the order of concerns
that Avalon has specified for those concerns.
|
A Stand Alone Program |
When you are designing a Component to be run from the command
line (or directly by the operating system), try to separate
the main function from the Component itself. This is imperative
in order to maintain the passive API of Avalon. By designing
you Component in the manner stated in the previous section,
you have effectively minimized what the main function has to
do.
Follow the practice of having an object dedicated to the main
function that includes the parsing of the command line parameters
and initialization of the Component. When the Component is used
the exact same way in every context (including the command line),
you minimize the number of locations to look while debugging.
A common mistake is to combine the main function in the
implementation of the Component. This requires violating the
contracts and principles that Avalon is built upon. This
violation of the pattern of "Inversion of Control" is
aptly dubbed "Subversion of Control" (thanks to Steven Coffman
for the name of the anti-pattern).
|
|
|