StoryOfThe6LifecycleMethods

UserPreferences

This wiki is in 'slumber' mode, just like its associated sourceforge project. Edits are disabled, the content is potentially stale and is not maintained. That said, it contains some really useful stuff still. Enjoy!

The Story Of The 8 Lifecycle Methods

On the first day, a JavaBean was born.

On the second day, the ugly JavaBean was refactored into a cute little component with 8 little resource delivery methods:

• its constructor
• setLogger( Logger logger );
• enableLogging( Logger logger );
• contextualize( Context context );
• service( ServiceManager serviceManager );
• compose( ComponentManager componentManager );
• parameterize( Parameters parameters );
• configure( Configuration configuration );

On the third day, the little component decided that the split between configuration and parameterization was dumb, and merged parameters into configuration:

  ConfigurationUtil.merge( 
    ConfigurationUtil.fromParameters( parameters ), 
    configuration ); 

And then there were 7.

On the fourth day, the little component felt that its configuration was really part of its context, and decided to merge its configuration into its context:

  context.get(Configuration.class.getName()); 

And then there were 6. Since the little component was feeling adventurous, it decided to remove the use of the ugly deprecated methods in another big surge of refactoring. It hadn't used those in days, after all.

And then there were 4.

On the fifth day, the component took a long hard look at the Context and ServiceManager classes it had gotten so used to working with. Amazingly, it turned out that the Context was actually a superinterface for the ServiceManager! It saddened the component a little that it had to replace the ServiceManager with the Context, since they had become intimate friends, but downsizing was all the rage these days.

And then there were 3.

The component lived happily for a while, until it heard about the no logging strategy on the sixth day, and decided that it had better replace its logger with a callback mechanism. Since that callback was again more generic than its logger, it had to let the latter go.

And then there were 2.

Now, the component thought realized that it had gradually shrunk itself from using 8 resource delivery methods to using only 2. It only really used the Context these days. It thought a while, then tried to remove its constructor. Too bad! Java requires a constructor. Well, no harm done; we'll remove hte context deliver method instead.

And then there was but 1, and the component lived happily ever after.

The moral in this story? Replacing

• constructor
• setLogger( Logger logger );
• enableLogging( Logger logger );
• contextualize( Context context );
• service( ServiceManager serviceManager );
• compose( ComponentManager componentManager );
• parameterize( Parameters parameters );
• configure( Configuration configuration );

with

• constructor

is a good idea. A lot more about that has been said already. Bite the bullet, become an IoC type-3 convert today!

Comments

Niclas Hedhman: IMHO, the whole Lifecycle described above is not Lifecycle at all, it is Construction (Birth). The Lifecycle does exist and can't be done in Constructor only. First of all we have a Destruction (Death), which in my opinion often is very important. Secondly, object instances should be more modern citizens and travel the world more. When they do, they need support for Transportation.

Leo Simons: I agree! Avalon-Framework currently splits up construction/birth into many different method calls. What I try and point out is that doing so might not make that much sense.

The contents of this wiki are licensed under a Creative Commons License.