很多人刚接触编程的时候，盯着factory这个单词发愣。查词典说是工厂，心里就犯嘀咕，代码里哪来的机器和流水线？我当年刚入行那会儿，也在这上面绕了不少弯路，总觉得这玩意儿深不可测。说白了，它就是个帮我们“造东西”的代理人，根本没那么玄乎。
我第一次被这玩意儿整懵的过程
记得那时候我接了个烂摊子项目，代码里到处都是直接new一个对象出来。比如要发个消息，代码里直接写死了一个短信类；明天要发邮件，又得跑去改源代码，把短信类删了换成邮件类。我改得头皮发麻，心想这玩意儿就不能像点外卖一样，我说要它就给我送啥吗？后来老大看我改得辛苦，扔给我一张图，让我去学学啥叫“工厂模式”。我当时第一反应是：我就是个写代码的，难不成还要我去厂里上班？
硬着头皮开始动手实践
我决定先把手里那堆乱七八糟的实例化代码给拆了。第一步，我先写了一个接口，把发消息这个动作给固定下来，管你是发短信还是发邮件，反正都得有个发送的方法。我建了一个专门叫MessageFactory的类。这个类里没啥高大上的逻辑，说白了就是一个大型的判断语句。我给它传个参数，要是写着“短信”，它就给我丢个短信的对象出来；要是写着“微信”，它就丢个微信的对象出来。
这样做完之后，我发现活儿轻快了不少。以前我想换个消息类型，得在业务逻辑里翻箱倒柜找哪里实例化了。现在好了，我只需要在调用工厂的时候改个名字，剩下的事情工厂内部自己就搞定了。这感觉就像家里请了个管家，我只要吩咐一声“今天吃肉”，他去市场买猪肉还是买牛肉我根本不用操心，等餐桌上摆好盘我直接动筷子就行。
实际操作中踩过的坑
虽然这玩意儿好用，但我中间也翻过车。有一阵子我魔怔了，觉得啥玩意儿都得套个工厂。哪怕只是一个永远不会变的简单对象，我也非得写个工厂去生产。结果到代码量翻了一倍，光是找那个工厂类在哪儿就得翻半天，项目结构变得臃肿不堪。后来我才明白，这东西是用来对付变化的。要是某个东西从项目开始到上线从来没变过，你还硬搞个工厂，那就是纯属给自己找不痛快。
总结出来的经验
- 别把简单的事情搞复杂：如果逻辑很简单，直接用最基础的静态工厂就行，别整那些花里胡哨的抽象工厂。
- 解耦才是硬道理：用了factory之后，你的业务代码就不用管那些对象是怎么造出来的了，以后想换个造法，直接去工厂里改，外面一点影响都没有。
- 看需求说话：如果一个对象有很多种变体，或者创建过程特别麻烦，那一定要上工厂。
现在回想起来，当初被这几个字母难倒确实挺傻的。技术这东西，脱离了那些高大上的名词，说到底就是为了偷懒。因为不想一遍遍写重复的创建代码，所以才整出个factory。你把它当成一个“代购”，想买啥直接下单，生活瞬间就美好了。我现在带新人的时候，也经常告诉他们，别被这些洋词儿吓着，写代码就是过日子，怎么方便怎么来，能让工厂干的活儿，咱们就别亲自上手了。
