使用静态工厂方法而不是构造器

注意：静态工厂方法不是设计模式中的工厂方法。

一个类向客户端提供静态工厂方法有以下好处：

• 有名称，不用根据参数类型和顺序区分重载方法，让代码更易读
• 是否每次调用都须要新对象是可控制的，对于不可修改的对象能够采起缓存对象来提升性能，例如可使用==来判断对象是否相等，而不使用equals，能够提升性能。
• 工厂方法体内可返回返回类型的任何子类型，这在选择返回对象的类型上有很大的灵活性。一个对外隐蔽了实现类（即所返回的对象的类型对外是不可见的）的API是很是紧凑的API。这种技巧自己把本身引导成了基于接口的框架（接口为静态工厂方法提供返回类型）。接口不能有静态方法，所以按惯例返回类型为接口Type的静态工厂方法会放在一个不可实例化的类Types中：例如Java集合框架中的Collections有32个对集合接口的很是方便的实现，分别提供不可修改集合、同步集合等等，几乎全部这些实现都是经过一个不可实例化的类（java.util.Collections）的静态工厂方法导出，这些工厂所返回的类都是非public的。当前集合框架API比导出32个public类要更小，不单只在API的代码量上获得减小，同时还在概念的重量级方面。用户一眼就知道所返回的对象正如接口所描述的同样，不须要读取额外的类实现文档。另外，使用这样一种静态工厂方法须要客户端使用接口来引用这个工厂方法所返回的对象，而不是使用实现类引用，这是一个好的实践。不仅由静态工厂返回的对象的类型能够是非public的，根据传入静态工厂的参数的不一样，这个返回对象的类也是可变的，只要是静态工厂方法声明的返回值类型的子类型就都是容许的。静态工厂返回值类型也是能够在各发布版间变化的，以加强可维护性和性能。Java1.5引入的java.util.EnumSet没有public构造器，只有静态工厂，这些静态工厂根据底层枚举类型的大小返回两个实现中的一个：若是元素小于等于64，静态工厂返回一个RegularEnumSet实例，它由单个long支持; 若是枚举类型有大于64个元素，静态工厂会返回一个JumboEnumSet实例，它由一个long数组支持。这两个实现类对客户端是不可见的。

     由静态工厂方法返回的对象的类甚至没必要在编写静态工厂方法所在的类时就存在。静态工厂的这种灵活性是服务提供者框架（service provider framework）的基石，例如JDBC。服务提供者框架是一个系统，在这个系统中，服务提供者实现服务，这个系统让这些实现对客户端可用，从而把客户端与实现分离。

     服务提供者框架有三个基本的组件：由提供者实现的服务接口、系统用于注册服务实现并让其对客户端可用的提供者注册API、客户端用于获取服务实现的服务访问API。服务访问API一般容许让客户端指定某些条件以便选择一个提供者，但客户端不是必需要指定，若是没有指定，API会返回一个默认实现。服务访问API就是构成服务提供者框架的基石的灵活静态工厂。

    服务提供者接口有一个可选的组件：服务提供者接口，由提供者用于建立他们本身的服务实现的实例。在没有服务提供者接口的状况下，实现是经过类名进行注册，并经过反射进行实例化。在JDBC中，Connection就是服务接口，DriverManager.registerDriver()就是服务提供者注册接口，DriverManager.getConnection()是服务访问接口，Driver是服务提供者接口。

    如今有许多服务提供者框架模式的变种，例如，经过使用适配器，服务访问API能够返回比提供者所须要的服务接口更加丰富的服务接口，下面是一个服务提供者接口及其一个默认实现:

// Service provider framework sketch
// Service interface
public interface Service {
    ... // Service-specific methods go here
}
// Service provider interface
public interface Provider {
    Service newService();
}
// Noninstantiable class for service registration and access
public class Services {
    private Services() { }  // Prevents instantiation (Item 4)
    // Maps service names to services
    private static final Map<String, Provider> providers =
        new ConcurrentHashMap<String, Provider>();
    public static final String DEFAULT_PROVIDER_NAME = "<def>";
// Provider registration API
    public static void registerDefaultProvider(Provider p) {
        registerProvider(DEFAULT_PROVIDER_NAME, p);
    }
    public static void registerProvider(String name, Provider p){
        providers.put(name, p);
    }
// Service access API
    public static Service newInstance() {
        return newInstance(DEFAULT_PROVIDER_NAME);
    }
    public static Service newInstance(String name) {
        Provider p = providers.get(name);
        if (p == null)
            throw new IllegalArgumentException(
                "No provider registered with name: " + name);
        return p.newService();
    }
}

• 减小建立参数化类型实现时的冗余信息

没有使用静态工厂时：

Map<String, List<String>> m = new HashMap<String, List<String>>();

使用静态工厂后：

public static <K, V> HashMap<K, V> newInstance() {
    return new HashMap<K, V>();
}

Map<String, List<String>> m = HashMap.newInstance();

遗憾的是，标准的集合类实现中，例如HashMap并无相似上面定义的工厂方法。但能够把这种方法放到本身的工具类中，更加剧要的是，能够在本身的参数化类中提供这种静态工厂方法。

 

只提供静态工厂方法的类的主要缺点在于不能被子类化，由于没有public或protected的构造器的类是不能被子类化的。

由public权限的静态工厂返回的非public类也是不能被子类化的，例如，不能子类化Collections里面的实现类，这能够说是塞翁失马，所以这样能够促进程序员使用组合而不是继承。

另外一个缺点在于静态工厂方法不易与其它静态方法区分开。

主要是由于静态工厂方法不像构造器那样明显地出如今API文档中，所以很难知道如何使用类中提供的静态工厂来代替构造方法实例化对象。能够经过在类或接口中写注释来讲明，而且让静态工厂方法名遵循约定：

valueOf、of、getInstance、newInstance、getType、newType

总之，静态工厂和构造方法各有优缺点，但一贯在使用构造器以前优先考虑使用静态工厂。