Avalon Design Documentation



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 Design Documentation : What is a component?


    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 limition: that of object codependency. 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.


    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.



    by Leo Simons



    Copyright © 1999-2001 The Apache Software Foundation. All Rights Reserved.