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!

Big O Notation

O(1) = Constant-time = Time to execute an algorithm or operation doesn't depend on size of input
Getting or accessing array element is a constant-time operation.

Constant-time is sort of "dream come true" for an algorithm, the best!


O(log n) = Logarithmic time = Time to execute an algorithm or operation is proportional to logarithm of size of input n.
Binary search on a sorted list is logarithmic in complexity.


O(n) = Linear time = Time to execute an algorithm or operation depends on size of input n, or is directly proportional to size of input n
Determining smallest element in an unsorted array is a linear-time operation.
Determining smallest element in an unsorted, fixed-size array can be considered as a constant-time operation (since n is a constant in this scenario).

Linear time is desirable attribute of an algorithm!


O(n log n) = Log-linear time
Heap sorting is log-linear in nature.


O(n^k) = Polynomial time = Time to execute an algorithm or operation is no greater than a polynomial function of a constant k irrespective of size of input n.
O(n²) = Quadratic time
O(n³) = Cubic time

Polynomial time is considered "fast" (enough) for an algorithm.


O(kⁿ) = Exponential time = Time to execute an algorithm or operation is an exponential function of size of input n.

Exponential time is (considered) "slower" than polynomial time for an algorithm.