【求喷系列】谁能普及下工厂模式的实际应用？我认为根本用不到?

Question

放假无聊在家看设计模式《head first系列》，今天看了工厂模式，分为三种：

1. 简单工厂模式

2. 工厂模式

3. 抽象工厂模式

首先这3个奇葩的名字，我真是醉了，虽说干了很多年，但是真还没怎么用过，这些东西都是各类框架实现的技术，比如spring，jdbc以及log4j之类的，真实的业务场景我还真没咋用过，谁帮忙普及下。
别整网上那些没营养的例子，什么汽车啊，鸭子啊，披萨啊，真是无聊，难道都不是用数据库表存各种属性吗？非要建立出那么多类，可能是想帮助人理解吧，但实际业务场景压根没有啊，谁说出来我服谁？求喷！

我后续还有若干求喷文，希望大家踊跃的喷我~

Answer 1

你说对业务上没有用到这个可以理解，还有不要认为只有类名称为Factory的才是工厂，比如UUID对象，目前有4种版本UUID，都不是new实例化的，通过一个Factory产出各种版本的UUID，通常这样设计的原因是为了解决大量同接口类的创建问题，经过分组抽象后，方便进行统一管理，类似的还有encoding charset

Answer 2

干了那么多年还是没遇到那就很悲剧了，首先可以考虑跳槽换家大公司你就会遇到了。
工厂模式最简单的就是关系型型/非关系型数据库切换，版本切换，类库切换。等等，你没遇到的原因是因为不需要后期维护或者根本不用考虑版本迭代，数据库更新吧？

其他的设计模式也是各有各的作用，这东西你没遇到感觉不重要，遇到了就会感觉这东西太好用了，十分巧妙的运用了类的封装，继承，多态。

再者，程序员进步就是研究框架源码，语言源码，大并发，代码可维护性。

Answer 3

就举个jdk的例子， Executors类它有个newFixedThreadPool的静态方法，接口定义如下：

public static ExecutorService newFixedThreadPool(int nThreads, ThreadFactory threadFactory) {

可以看到，第二个参数是可以传入一个线程工厂，然后Executors类就可以根据工厂方法来创建线城池需要的线程。换句话说，就是你可以把你要创建线程的规则都写在ThreadFactory中咯。比如说，让该工厂创建的线程名字都为XXX-前缀、或者指定线程优先级等等。

这个可以说是工厂模式最常见的场景，在各个框架的应用比比皆是。学习设计模式，啃书之余多看实际代码，自然才会发现模式具体作用，甚至是各种巧用的技巧。

Answer 4

不论是工厂模式还是其它创建型模式，都是一个目的——为了初始化一个对象。或者说，为了构建一个数据结构模型（类和对象本身就是一种自定义的数据结构）。

那么，问题来了，为什么有 new 这样方式可以创建一个对象，还要使用设计模式。本质上就是一个原因，不想让上层使用者直接使用 new 来初始化对象。

这样的原因有很多，绝大多数原因就是对上层的使用者隔离对象创建的过程；或者是对象创建的过程复杂，使用者不容易掌握；或者是对象创建要满足某种条件，这些条件是业务的需求也好，是系统约束也好，没有必要让上层使用者掌握，增加别人开发的难度。

所以，到这时我们应该清楚了，无论是工厂模式，还是上面的战友说的开闭原则，都是为了隔离一些复杂的过程，使得这些复杂的过程不向外暴露，如果暴露了这些过程，会对使用者增加麻烦，这也就是所谓的团队合作。

面向对象封装的本身也就是为了使得对外的 API 尽可能的简化。

例如，你定义了一个 Status字段，但这个字段因为某些业务原因，需要使用整数来表示状态。那么，如果数字少了还好办，如果数字多了，上层使用者就不一定能记清楚每个数字代表的状态（比如你要做语音通信系统，那么，语音设备是有很多状态数字的）。这时，如果使用 new来创建对象，然后再对 Status 进行赋值，不可避免的，可能要查阅开发文档，或者会不小心给出一个错误的值。这时，你就不妨使用工厂模式，或者其它合适的设计模式，来进行代码的建设。

比如，这样：

public static class Factory
{
    public static Ixxxxxx CreateWithOpen()
    {
        var obj = new Obj();
        obj.Status = 1;
        return obj;
    }
    public static Ixxxxxx CreateWithClose()
    {
        var obj = new Obj();
        obj.Status = 2;
        return obj;
    }
}

当然，使用枚举也行，这个说白了，就是看设计者的意愿了。

所以，设计模式没有说必需在哪个场景中使用，更确切的说，应该是，当你使用了设计模式，能不能为你的团队成员带来方便，或者提升代码质量，避免一些错误。如果是，就用，如果仅仅带来了复杂，并没有益处，那还是算了。

一句话，没有该不该用，也没有哪些需要不需要用，用就要带来效益，无论是对团队还是产品质量或产品的可维护性。用不用，要以团队配合和产品为导向，这才是对一个软件设计师的基本要求。