Effective Java

// Inappropriate use of static utility - inflexible & untestable!
public class SpellChecker {
private static final Lexicon dictionary = ...;
private SpellChecker() {} // Noninstantiable
public static boolean isValid(String word) { ... }
public static List suggestions(String typo) { ... }
}
Similarly, it’s not uncommon to see them implemented as singletons (Item 3):
// Inappropriate use of singleton - inflexible & untestable!
public class SpellChecker {
private final Lexicon dictionary = ...;
private SpellChecker(...) {}
public static INSTANCE = new SpellChecker(...);
public boolean isValid(String word) { ... }
public List suggestions(String typo) { ... }
}
Neither of these approaches is satisfactory, because they assume that there is
only one dictionary worth using. In practice, each language has its own dictionary,
and special dictionaries are used for special vocabularies. Also, it may be
desirable to use a special dictionary for testing. It is wishful thinking to assume
that a single dictionary will suffice for all time. 
You could try to have 
SpellChecker
support multiple dictionaries by making
the 
dictionary
field nonfinal and adding a method to change the dictionary in an
existing spell checker, but this would be awkward, error-prone, and unworkable in
a concurrent setting. 
Static utility classes and singletons are inappropriate for
classes whose behavior is parameterized by an underlying resource. 
What is required is the ability to support multiple instances of the class (in our
example, 
SpellChecker
), each of which uses the resource desired by the client (in
our example, the dictionary). A simple pattern that satisfies this requirement is to
pass the resource into the constructor when creating a new instance
. This is
one form of 
dependency injection
: the dictionary is a 
dependency
of the spell
checker and is 
injected
into the spell checker when it is created.

---

ITEM 5: PREFER DEPENDENCY INJECTION TO HARDWIRING RESOURCES
21