|
Jakarta main
Avalon main
About
Patterns and Design
The API
|
Avalon Design Documentation
Avalon Design Documentation
|
Introduction to COP |
Component Oriented Programming, or COP for short, takes Object Oriented
Programming one step further. Regular OOP organizes data object into
entities that take care of themselves. There are many advantages to this
approach. I'll assume that you, being a java programmer, are familiar
with those.
It also has a big limitation: that of object co-dependency. To remove that
limitation, a more rigid idea had to be formalized: the Component. The key
difference between a regular object and a component is that a component is
completely replaceable.
There is a lot of buzz in the industry touting Component Based Design
(CBD). You will find, that the definition of a Component in Avalon
is more formal than most companies' definition of a Component. Any
system developed with the principles of Avalon can claim CBD. In
fact the Avalon Framework formalizes CBD more rigidly than the marketing
definition. Do not be fooled though, CBD and COP aren't necessarily
the same thing. Component Based Design refers to how a system is
designed and not how it is implemented. Component Oriented Programming,
on the other hand, refers to how a system is implemented and not how
it is designed. In practice, you can't implement COP without first
designing with Components in mind.
|
Components in Avalon |
At the core of the Avalon framework is the Component. We define it as "a
passive entity that performs a specific role". This is important to grasp
because it requires a specific way of thinking.
A passive API |
A passive entity must employ a passive API. A passive API is one that is
acted upon, versus one that acts itself. See the
Inversion of Control pattern
for an explanation.
|
A specific Role |
The concept of roles come from the theater. A play, musical,
or movie will have a certain number of roles that actors play.
Although there never seems to be a shortage of actors, there
are a finite number of roles. I am not going to make reference
to different types of roles at this point, but simply bring
the concept to light. The function or action of a role is
defined by it's script.
We are introducing this concept now because you need to have it
in mind when you are designing your system architecture. Think
of the different roles in your system, and you will have your
"cast" of components so to speak.
For each role, you need to specify it's script, or interface to
the rest of the system. To be honest the interface is not enough.
There are specific contracts that you must define and keep in mind
when you specify your interfaces. In other words, what users
of the Component must provide, and what the Component produces.
When the interface and contract are defined, you can work on your
implementation.
|
|
Writing the Component |
John Milton wrote, "No man is an island." to communicate that we
are all interdependent. The same is true for the Component. That
is why there are different concerns regarding the Component. In
the section on roles we specified one of the concerns: the role.
The concerns directly supported by Avalon are: configuration,
external component use, management, and execution.
As you might of guessed, each one of these concerns has a separate
interface that describes that concern. We will delve deeper into
the interfaces and the reasoning behind them in other sections. It
is important to know the order of precedence for the concerns so
that you know the overall contracts of how they are put together.
-
Configurable: marks an object that can be configured.
-
Composable: marks an object that uses Components.
-
Initializable: marks an object that can be initialized.
-
Disposable: marks an object that can be disposed.
-
Stoppable: marks an object that can be started and stopped.
The contract surrounding this order means that the methods defined
by each of those interfaces are called in a specific order by the object
that created the Component. Each interface represents a narrow view
of the Component or object being controlled.
Notice that each interface is separate from Component, so you can use
them for simple objects.
|
|