Pico Container

# About

- What is PicoContainer?
- Introduction
- Javadoc
- Downloads
- News
- FAQ
- Project Goals
- Support

# Core Concepts

- Component Lifecycle
- Dependency Injection
- Scoped Containers

# Dependency Injection

- Constructor Injection
- Setter Injection
- Annotated Field Injection
- Annotated Method Injection
- Typed Field Injection
- Named Field Injection
- Method Injection
- Multiple Injection
- Composite Injection
- Factory Injection
- Reinjection
- Injection via Providers

# Configuration

- Disambiguation

# Modifying Component Behaviors

- Modifying Behaviors
- Caching and Singletons
- Hiding Implementations
- Thread Safety Behaviors
- AOP Style Interception

# Advanced Concepts

- Fluent Style
- Arrays, Collections and Maps
- Leveraging Parameter Names
- Building Containers
- Component Properties
- Component Configuration
- Monitoring Component Events

# PicoContainer's Architecture

- Design Patterns
- Inversion of Control
- Component Adapters
- Mock Objects
- Terminology
- Container Comparisons
- Transparency

# Container Choices

- DefaultPicoContainer
- CommandLinePicoContainer
- PropertiesPicoContainer
- SystemPropertiesPicoContainer
- TransientPicoContainer
- TieringPicoContainer

# Dependant & Related

- Web Frameworks
- Scripting Support
- Persistence
- Logging

# Anti-patterns

- Propagating Dependency
- Long Constructor Argument List
- Container Dependency
- Unit Tests Use Container
- Singleton

# Help Pages

- Ambiguous Injectable
- Unprocessed Properties

# History

- Inversion of Control History

# Project Info

- Project
- Team

# Hosted by

# Tools

## Design Patterns

### Key Patterns

Inversion of Control (IoC).

The idea that an application is controlled from the top down

Separation of Concerns (SoC)

The idea that a class (aspect) should do one job and do it well

Separation of API (or Interface) from Implementation

The idea that you define and code to work interfaces

Aspect Oriented Programming (AOP)

Mostly lightweight nowadays where you add a chain of interceptors around a method call that can handle orthogonal concerns

Component Oriented Programming (COP)

The idea that you decompose your software into components

Declarative Programming

Where you use a declarative-style language (usually xml) to determine things like component wiring (i.e. your average tomcat config file, generalized)

Event Based Programming (EBP)

Basically making the inter-object method call asynchronous and encapsulating such a call into some kind of event object that can be queued, modified, etc

### More Thinking

Good Citizen: Least surprise, least paranoia

Authors: Dan North, Aslak Hellesoy

Imagine a software system where there is no need for you to spend your time programming defensively; your objects will be used responsibly, and your methods will always be passed sensible arguments.

This low-friction utopia can be approached by establishing some simple programming rules so that every class acts as a 'good citizen' in the society of classes collaborating at runtime.

This page outlines some rules that we, and others, believe lead to good citizenship. All are aimed at improving clarity, reducing surprise, and promoting basic consistency.

As a good citizen, I...

- Keep a consistent state at all times - init() or populate() is a code smell.
- Have no static fields or methods
- Never expect or return null.
- Fail fast - even when constructing.
- Am Easy to test- all dependent object I use can be passed to me, often in my constructor (typically as Mock Objects).
- Accept dependent object that can easily be substituted with Mock Objects (I don't use Concrete Class Dependency).
- Chain multiple constructors to a common place (using this(...)).
- Always define hashCode() alongside equals()
- Prefer immutable value objects that I can easily throw away.
- Have a special value for 'nothing' - e.g. Collections.EMPTY_SET.
- Raise checked exceptions when the caller asked for something unreasonable - e.g. open a non-existant file.
- Raise unchecked exceptions when I can't do something reasonable that the caller asked of me - e.g. disk error when reading from an opened file.
- Only catch exceptions that can be handled fully.
- Only log information that someone needs to see.

Classes that are designed for Constructor Injection are better citizens than those that are not.