Dependency Injection = GoF Builder

http://www.martinfowler.com/articles/injection.html

Component = Software that is intended to be used, without component-source-code change, by client applications. Component and it's client are typically co-located, e.g. in same JVM or in same executable.
Service = Service and it's client are not co-located, or client accesses a remote service.

If you see

public interface Injector {
public void inject(Object target);
}

, it injects (or sets) target to act on for a component. Basically, a setter on a component that implements Injector-interface.

Tester class or Assembler (actor) is nothing but a GoF-Builder-participant-Director that knows how to construct a GoF-Builder-participant-Product (MovieLister) that has GoF-Builder-BuildPart (MovieFinder).

Can we then say that Dependency Injection is nothing but configuring a GoF-Strategy (or algorithm in general) using GoF-Builder pattern?
Or, in general, Dependency Injection is nothing but GoF-Builder?

Builder is supposed to separate the construction of complex object (data and procedures that operate on that data - a GoF-Builder-participant-Product, or MovieLister in Martin's link above) from its representation (MovieLister with certain implementation of MovieFinder in Martin's link above).


Dependency Injection (DI) is referred as specific case of the general pattern "Inversion of Control", i.e. how framework invokes call-backs from client source code. For example, how MovieLister (say part of framework source code) invokes MovieFinder (say part of client source code). Inversion is in terms of framework invoking client, rather than the most typical case of client invoking framework methods.


http://java.sun.com/developer/technicalArticles/J2EE/injection/

Java-EE 5 seems to be using such DI using Java-SE Annotations mechanism. The Java-EE 5 Web/Application Container is the Builder-Director that builds Java-EE-components like Servlets, EJBs. The Java-EE-components are the Builder-Products.

Java-EE 5 Annotations (examples at least) seem to promote hard-coding of such "dependency" names-or-identifiers, e.g.

@Resource(name="jms/demoTopic")
private javax.jms.Topic demoTopic;

Just wondering if it's possible to pass such names dynamically to the annotation!