This interface is implemented by objects that hold a number of bean definitions, each uniquely identified by a String name. Depending on the bean definition, the factory will return either an independent instance of a contained object (the Prototype design pattern), or a single shared instance (a superior alternative to the Singleton design pattern, in which the instance is a singleton in the scope of the factory). Which type of instance will be returned depends on the bean factory configuration: the API is the same. The Singleton approach is more useful and more common in practice.

The point of this approach is that the BeanFactory is a central registry of application components, and centralizes configuration of application components (no more do individual objects need to read properties files, for example). See chapters 4 and 11 of "Expert One-on-One J2EE Design and Development" for a discussion of the benefits of this approach.

Note that it is generally better to rely on Dependency Injection ("push" configuration) to configure application objects through setters or constructors, rather than use any form of "pull" configuration like a BeanFactory lookup. Spring's Dependency Injection functionality is implemented using BeanFactory and its subinterfaces.

Normally a BeanFactory will load bean definitions stored in a configuration source (such as an XML document), and use the org.springframework.beans package to configure the beans. However, an implementation could simply return Java objects it creates as necessary directly in Java code. There are no constraints on how the definitions could be stored: LDAP, RDBMS, XML, properties file etc. Implementations are encouraged to support references amongst beans, to either Singletons or Prototypes.

In contrast to the methods in ListableBeanFactory, all of the methods in this interface will also check parent factories if this is a HierarchicalBeanFactory. If a bean is not found in this factory instance, the immediate parent is asked. Beans in this factory instance are supposed to override beans of the same name in any parent factory.

Bean factory implementations should support the standard bean lifecycle interfaces as far as possible. The maximum set of initialization methods and their standard order is:
1. BeanNameAware's setBeanName
2. BeanFactoryAware's setBeanFactory
3. ResourceLoaderAware's setResourceLoader (only applicable when running in an application context)
4. ApplicationEventPublisherAware's setApplicationEventPublisher (only applicable when running in an application context)
5. MessageSourceAware's setMessageSource (only applicable when running in an application context)
6. ApplicationContextAware's setApplicationContext (only applicable when running in an application context)
7. ServletContextAware's setServletContext (only applicable when running in a web application context)
8. postProcessBeforeInitialization methods of BeanPostProcessors
9. InitializingBean's afterPropertiesSet
10. a custom init-method definition
11. postProcessAfterInitialization methods of BeanPostProcessors

On shutdown of a bean factory, the following lifecycle methods apply:
1. DisposableBean's destroy
2. a custom destroy-method definition