effective java 第三版 条目5 使用依赖注入来连接资源更好

      许多类都会依赖一个或者多个潜在的资源，例如一个拼写检查依赖一个字典。很容易就可以看见一个使用这样实现的静态工具类。（条目4）

//  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) { ... }

}

 相似的，很容易看到他们作为单例来实现（条目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) { ... }

}

    这两个方案都不是静态工厂，因为他们都假定只有一个字典类可以被使用。实际上，每一种语言都有他们的字典，同时特定的字典通常被使用到特地的词汇上。所以，使用一个特定的字典来测试的设计可能并不令人满意，而思考假定一个字典能够满足所有的需求是明智的！

     你可能会尝试让SpellChecker 的dictionary 这个字段不是final的，同时添加一个方法来在当前存在的所有dictionary 的范围内改变一个dictionary 这个字段，这样可以使SpellChecker 支持多个字典。但是将会让人很尴尬，又很容易让人因为使用了错误的设置而出错。静态工具类和单例模式出现在一个参数会因为潜在的资源发生变化的类中是不恰当的。

     现在的需求是，能够去支持这个类的多个实例，每一个都会使用到客户端的一些资源（在这个例子中，是我们的dictionary），一个满足这样需求的简单的模式是当创建一个新的实例的时候将这些资源传入构造器中，这形成了依赖注入：这个dictionary是SpellChecker 的一个依赖，然后我们在SpellChecker 将dictionary注入到对象中去。

    // Dependency injection provides flexibility and testability

  public class SpellChecker {

      private final Lexicon dictionary;

      public    SpellChecker(Lexicon    dictionary)     { this.dictionary = Objects.requireNonNull(dictionary);}

     public boolean isValid(String word) { ... }

     public List suggestions(String typo) { ... }

}

     这个依赖注入模式非常简单，以至于很多程序员使用了很多年都不知道它有一个名字。但是我们的拼写例子只有一个资源的依赖，依赖注入却是可以在任意数量的资源和任意规模的依赖图中工作！它保证了不能改变的特性，所以多个客户端能够共享这些依赖对象（假设这些客户端都潜在地期望着相同的资源）。依赖注入和构造器，静态工厂（条目1），和建造者模式（条目2）相等。

  这个模式一个非常有用的变体是，通过一个资源工厂将资源注入到构造器中，一个工厂是一个可以重复调用的可以创建出一个实例的对象，这样的工厂表现为工厂方法模式。这个Supplier接口被添加到java8中，它可以很好地去提供一个工厂。使用通配符的泛型特性，方法的输入典型地强迫指定工厂参数类型来允许工厂可以创建一个指定类型的子类型。例如这里有一个方法，客户端使用提供的可以创建任意类型的工厂创建mosaic。

      尽管依赖注入很好地提高了灵活性和可测试性，但是他可能会使一个包含成千上万的依赖的大型工程变得散乱。不过这种散乱可以被依赖注入框架所排出，诸如：Dagger,Guice,Spring。这些框架的使用超过了这本书的范围，但是记住那些由这些框架为了依赖注入而设计出来的细致的API是非常容易使用的。

   总结：不使用单例模式或者静态工具类来实现一个依赖超过一种隐含资源依赖的类，这些隐含资源的表现会影响整个类的效果！同时这些资源的在类的之前被创建。取而代之的是，通过将这些资源和工厂传入构造器。实际上，依赖注入将会更好地提高一个类的灵活性，复用性，和可测试性！