Avalon Developer 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 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



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