目录

• 背景
• 情景一：不同参数数目的构造器
• 情景二：不同种类的汉堡
• 情景三：自定义汉堡的做法
• 什么是静态工厂方法
• 静态工厂优缺点
• 优点
• 缺点
• 静态方法命名规范
• 小结
• 参考资料

背景

假如现在你要想一个汉堡，有一个汉堡类：Hamburg。那么一般情况下你会：

Hamburg hamburg = new Hamburg();

情景一：不同参数数目的构造器

制作汉堡可以选择自定义，加肉，加菜，或者不添加，直接默认配方即可，那么会有以下几个构造器：

Hamburg();
Hamburg(Meat meat);
Hamburg(Meat meat,Vegetable vegetable);

当你要制作汉堡的时候，看到这么多的构造器，但是却不知道他们是什么意思，返回的汉堡到底有什么区别？查文档又有点麻烦，有没有更好的解决方法呢？

情景二：不同种类的汉堡

如果有多种汉堡：新奥尔良汉堡，麦辣香汉堡。常规的做法就是：继承汉堡类，实现子类，如：

class xinaoerliangHamburg extends Hamburg{}
class mailaHamburg extends Hamburg{}

但是会有问题：用户在使用的时候，还得记住你那么多类名，那是不是很麻烦？如果后续有更多的口味，那是不是要记住更多地类去才能得到对应的实例呢？有没有更好的解决方法？

情景三：自定义汉堡的做法

如果汉堡的手法让你非常不满意，你想要用达芬奇技法来制作汉堡，那么可以怎么做呢？常规的做法是：

class Hamburg{
 ...
 //默认制作手法 
 private Maker mMaker = new DefaultMaker(); 
 public Hamburg(Maker maker){
  ...
  //使用传进来的手法对象制作汉堡
  mMaker = maker;
  ...
 }
}

需要重新写一个构造器，传入参数来覆盖原来的制作手法。这样既有情景一的问题，还有另外的问题是：如果需要自定义的东西多的时候，那么Hamburg里需要维护的代码就更加的复杂了。

什么是静态工厂方法

以上情景问题可以通过静态工厂方法来改善。

注意，这里的静态工厂方法并不是设计模式中的工厂模式。这里只是使用静态工厂方法来代替构造器实例化对象。

顾名思义，静态工厂方法，就是使用静态方法来构建类的实例，解决使用构造器实例化的各种问题。先看个例子，还是以上面的汉堡为例子，如果需要多种口味的汉堡，那么可以：

class Hamburg{

 //获取奥尔良口味的汉堡
 public static Hamburg ofAoErLiang(){
  return new AoErLiangHamburg();
 }
 //获取麦辣香味的汉堡
 public static Hamburg ofMaiLaXiang(){
  return new MaiLaXiangHamburg();
 }
}

//两种口味的汉堡，通过继承汉堡实现
class AoErLiangHamburg extends Hamburg{}
class MaiLaXiangHamburg extends Hamburg{}

通过这种方法可以解决的是：用户需要什么类型的汉堡，可以直接通过Hamburg的静态方法来获取，而无需知道他的子类名字是什么。而如果有更多种口味的汉堡，只需要扩展静态方法即可；或者给静态方法增加参数，通过switch来返回对应的口味汉堡。

静态工厂优缺点

这里的话会结合上面举的例子，如果忘记了，看到可以返回去看一下。

优点

• 解决构造器重载却不知道各种构造器含义的问题。通过构造方法可以在方法名写明，那么用户只需要通过方法名就知道这个方法是返回什么对象。（例如情景一）例如：

//不同的静态工厂方法返回不同的实例，通过方法名就知道他们的区别
//ps：这是android的动画类
ObjectAnimator animator = ObjectAnimator.ofFloat();
ObjectAnimator animator = ObjectAnimator.ofInt();

• 可以通过根据用户的参数或者调用不同的静态工厂方法来返回具体的子类对象。当后期要更换方法接口返回的子类时，对于用户来说也是透明的，用户只是拿到一个父类引用的对象。可以参考上面我在介绍静态工厂方法举的例子。

Java 8以上，可以在接口中定义静态工厂方法，这样无需知道该接口有多少个实现类，只需要根据静态方法来获取接口对象即可。

• 重复利用对象，防止创建无用实例。这看起来很像单例，但是比单例要灵活得多。可以根据具体的情况，来判断是否要缓存实例。
• 可以动态注册代码。我们可以通过一组用户注册api，让用户先把需要的自定义代码注入，再调用静态方法来获取自己需要的对象类型。这样的好处就是不会有一堆很复杂的构造器，内部逻辑也可以分离。对应情景三解决的问题

缺点

1. 如果该类不包含public或者protect构造器，那么将无法被子类实例化。因为我们想要用户通过静态方法来获取对象，而不喜欢用户通过构造方法来实例化对象。而如果把构造器设置为private，则无法被子类继承。
2. 无法在javadoc中直接查看文档介绍，构造器是会直接生成doc的。但是直接通过方法名和参数名，已经可以看懂很多了。
   

静态方法命名规范

小结

在有多种子类或者重载构造器的时候，可以优先考虑一下静态工厂方法，可以让我们的代码更加地优雅，也方便我们进行维护。
另外这和设计模式中的工厂模式有区别，并不是一样的，要进行区分。

参考资料

《effective java》

以上就是java 静态工厂代替多参构造器的详细内容，更多关于java 静态工厂的资料请关注其它相关文章！