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.

  1. Configurable: marks an object that can be configured.
  2. Composable: marks an object that uses Components.
  3. Initializable: marks an object that can be initialized.
  4. Disposable: marks an object that can be disposed.
  5. 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.



Copyright ©1999-2002 by the Apache Software Foundation. All Rights Reserved.