This refactoring introduces two new classes: LifecycleManager and LifecycleManagerFactory. The rationale behind this refactoring is to allow pluggable lifecycle mechanisms/strategies. The motivation for this is that users have different requirements for lifecycle algorithms. Lifecycle management (LM) and dependency resolution (DR) are two separate concerns. This refactoring moves these separate concerns into different interfaces. An instance of a LifecycleManagerFactory can now be passed to a DefaultPicoContainer's constructor. The other (old) constructors remain the same, calling the new constructor with a DefaultLifecycleManagerFactory. This factory creates DefaultLifecycleManager instances, which encapsulate the previous lifecycle algorithm that used to be in DefaultPicoContainer. The lifecycle methods start(), stop() and dispose() remain on DefaultPicoContainer for backwards compatibility, but they have been deprecated in order to favour the new design. If this refactoring is backed by a majority of the developers, the exixting code in NanoContainer should be refactored from pico.start() to pico.getLifecycleManager().start() etc. (Very simple). Another nice effect from this refactoring is that we can now allow component developers to cherry-pick their own lifecycle methods, removing the requirement to implement the PicoContainer Startable and Disposable interfaces when lifecycle is needed. Additional LifecycleManager/LifecycleManagerFactory classes leveraging proxytoys multicast or other can now be used in conjunction with DefaultPicoContainer and everything in NanoContainer.