Skip to end of metadata
Go to start of metadata

Authors: Paul Hammant

Overview

Configuration for PicoContainer components requires some explanation. The basic idea is that a component should not be tied to a single configuration design.

There are two ways a developer may declare configuration needs for a component. The first is as seperate parameters in the constructor, the second is as a bespoke configuration pseudo-component, also passed in through constructor.

Constructor parameters

Consider a component a that requires configuration :

Clearly the string and the integer are not components. What we need is a way of passing in those parameters at runtime. Possibily interleaved with real components.

We're trying to illustrate the intermingling of components and configuration. Well perhaps we are if you consider the following component :

Pseudo-component

Without going into the how, many implementations of the FooConfig are possible.

Clearly a person needs to write an adaptor, but any adaptor can be written. The developer who uses the component can do anything - they are not forced to fit one configuration design.

Anti-patterns
In non IoC designs, a component may hard code its configuration in one of a number of ways.

True hard coding:

Bound to a specific properties file:

There are IoC anti-patterns as the embedor can't choose their own configuration mechanism. An application comprising a number of components may have to include multiple xml and properties files to control the configuration.

  • No labels