44 | 工厂模式（上）：我为什么说没事不要随便用工厂模式创建对象？

精选留言

• 
  逍遥思

  2020-02-12

  复杂度无法被消除，只能被转移：
  
  - 不用工厂模式，if-else 逻辑、创建逻辑和业务代码耦合在一起
  - 简单工厂是将不同创建逻辑放到一个工厂类中，if-else 逻辑在这个工厂类中
  - 工厂方法是将不同创建逻辑放到不同工厂类中，先用一个工厂类的工厂来来得到某个工厂，再用这个工厂来创建，if-else 逻辑在工厂类的工厂中

  16

  278
• 
  zhengyu.nie

  2020-04-24

  个人意见，传统的工厂模式太麻烦了，除非业务真的很复杂，通常我会选择以下方案。
  还是举文中的例子
  
  1.将不同的RuleConfigParser实现按照约定格式指定beanName注入，比方说@Component(“XmlRuleConfigParser”)，取的时候applicationContext.getBean(typeSuffix+RuleConfigParser)即可，拓展的话，自己写一个xxRuleConfigParser，就注入进去了，也不需要在map容器新增。
  整个工厂方法就是
  public RuleConfigParser getInstance(suffix){
      return InstanceLocator.getBean(suffix+"RuleConfigParser");
  }
  
  
  2.直接用java.util.functional实现现代函数式编程范式的设计模式
  像文中的例子,可以看作工厂,也可以看作获取一种parse策略。
  可以有一个FunctionFactory内部维护一组Function<String,String>函数，再有一个Map容器 mapping type和Function的关系。这样是简化了类的数量，如果业务简单没必要整太多类，function铺在一个factory里可读性不会有什么问题。如果是没有返回值的操作，也可以用Consumer函数。打个比方
  
      public BiConsumer<AbstractProductServiceRequest, Function<ProductServiceQueryRequest,
          ProductServiceQueryResponse>> operateConsumer() {
          switch (serviceOperationEnum) {
              case OPEN:
                  return openConsumer();
              case CLOSE:
                  return closeConsumer();
              default:
                  throw new RuntimeException("not support OperationType");
          }
      }
  
  如果是对象，那更简单，Map<Supply>函数即可。
  
  public class ShapeFactory {
    final static Map<String, Supplier<Shape>> map = new HashMap<>();
    static {
      map.put("CIRCLE", Circle::new);
      map.put("RECTANGLE", Rectangle::new);
    }
    public Shape getShape(String shapeType){
       Supplier<Shape> shape = map.get(shapeType.toUpperCase());
       if(shape != null) {
         return shape.get();
       }
       throw new IllegalArgumentException("No such shape " + shapeType.toUpperCase());
    }
  }
  
  
  以上个人意见，对于比较简单的场景，lambda function等方式代替类，会显得不那么臃肿，具体还是要看需求。至于OOP等原则，也不是完全要遵守的，就像争哥说的少量if可以不管，一样的道理，灵活运用。

  展开

  作者回复: 👍

  22

  121
• 
  porter

  2020-02-12

  我把Head First的定义贴过来，方便大家理解总结
  
  工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类
  
  抽象工厂模式：提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类

  3

  38
• 
  辣么大

  2020-02-12

  在JDK中工厂方法的命名有些规范：
  1. valueOf() 返回与入参相等的对象
  例如 Integer.valueOf()
  2. getInstance() 返回单例对象
  例如 Calendar.getInstance()
  3. newInstance() 每次调用时返回新的对象
  例如 HelloWorld.class.getConstructor().newInstance()
  4 在反射中的工厂方法
  例如 XXX.class.getField(String name) 返回成员
  
  静态工厂方法的优点：
  1. 静态工厂方法子类可以继承，但不能重写，这样返回类型就是确定的。可以返回对象类型或者primitive 类型。
  2. 静态工厂方法的名字更有意义，例如Collections.synchronizedMap()
  3. 静态工厂方法可以封装创建对象的逻辑，还可以做其他事情，让构造方法只初始化成员变量。
  4. 静态工厂方法可以控制创建实例的个数。例如单例模式，或者多例模式，使用本质上是可以用静态工厂方法实现。

  展开

  5

  25
• 
  Brian

  2020-02-13

  一、三种工厂模式
    1. 简单工厂（Simple Factory）
      使用场景：
        a. 当每个对象的创建逻辑都比较简单的时候，将多个对象的创建逻辑放到一个工厂类中。
      实现：
        a. if else 创建不同的对象。
        b. 用单例模式 + 简单工厂模式结合来实现。
    2. 工厂方法（Factory Method）
      使用场景：
        a. 当每个对象的创建逻辑都比较复杂的时候，为了避免设计一个过于庞大的简单工厂类时，将创建逻辑拆分得更细，每个对象的创建逻辑独立到各自的工厂类中。
        b. 避免很多 if-else 分支逻辑时。
      实现：
        a. 定义相应的ParserFactory接口，每个工厂定义一个实现类。这种方式使用会有多个if else 让使用更加复杂。
        b. 创建工厂的工厂来，此方案可以解决上面的问题。
    3. 抽象工厂（Abstract Factory）- 不常用
      使用场景：
        a. 有多种分类方式，如方式要用一套工厂方法，方式二要用一套工厂方法，详见原文例子。
      实现：
        让一个工厂负责创建多个不同类型的对象（IRuleConfigParser、ISystemConfigParser 等），而不是只创建一种 parser 对象。
  
  二、例子
    刚好最近有这方面的应用场景，主要使用了 单例模式 + 工厂模式 + 策略模式，用于解化多过的if else的复杂性。
  
  public class OrderOperateStrategyFactory {
      /**
       * 消费类型和策略对象映射。
       */
      private Map<CheckoutType, OrderOperateStrategy> map;
  
      /**
       * 构造策略列表。
       */
      private OrderOperateStrategyFactory() {
          List<OrderOperateStrategy> list = new ArrayList<>();
          list.add(SpringContextHolder.getBean(ConsumptionOrderOperateStrategy.class));
          list.add(SpringContextHolder.getBean(GroupServiceOrderOperateStrategy.class));
          //...
          map = list.stream().collect(Collectors.toMap(OrderOperateStrategy::getCheckoutType, v -> v));
      }
  
      /**
       * 通过消费类型获取订单操作策略。
       *
       * @param checkoutType 消费类型
       * @return 订单损我策略对象
       */
      public OrderOperateStrategy get(CheckoutType checkoutType) {
          return map.get(checkoutType);
      }
  
      /**
       * 静态内部类单例对象。
       */
      private static class Holder {
          private static OrderOperateStrategyFactory INSTANCE = new OrderOperateStrategyFactory();
      }
  
      /**
       * 获取订单操作策略工厂类实例。
       *
       * @return 单例实例。
       */
      public static OrderOperateStrategyFactory getInstance() {
          return Holder.INSTANCE;
      }
  }
  
  使用：
  OrderOperateStrategy strategy = OrderOperateStrategyFactory.getInstance().get(checkoutType);
  strategy.complete(orderId);

  展开

  3

  21
• 
  跳跳

  2020-08-10

  我觉得很多人被带跑偏了 工厂本身的重点不是解决if else 而是解决简单工厂的开闭原则，大家都在重点讨论if else 即使被省略了 也是map的功劳啊

  

  18
• 
  Jxin

  2020-02-13

  分歧：
  1.文中说，创建对象不复杂的情况下用new，复杂的情况用工厂方法。这描述没问题，但工厂方法除了处理复杂对象创建这一职责，还有增加扩展点这优点。工厂方法，在可能有扩展需求，比如要加对象池，缓存，或其他业务需求时，可以提供扩展的地方。所以，除非明确确定该类只会有简单数据载体的职责（值对象），不然建议还是用工厂方法好点。new这种操作是没有扩展性的。
  
  回答问题：
  2.工厂方法要么归于类，要么归于实例。如果归于实例，那么第一个实例怎么来？而且实例创建出另一个实例，这种行为应该称为拷贝，或则拆分。是一个平级的复制或分裂的行为。而归于类，创建出实例，是一个父子关系，其创建的语义更强些。
  我认为不影响测试。因为工厂方法不该包含业务，它只是new的一种更好的写法。所以你只需要用它，而并不该需要测它。如果你的静态工厂方法都需要测试，那么说明你这个方法不够“干净”。

  展开

  

  15
• 
  李小四

  2020-02-23

  设计模式_44:
  # 作业
  1. Android开发中工厂模式也很常用，比如`BitmapFactory`类；用工厂模式的原因是`Bitmap`对象的创建过程比较复杂，并且可以通过不同的方式来创建。
  
  2. 查了一下资料，意识到这个问题的核心在于使用*静态工厂方法*替代的是使用构造函数，之所以用*静态方法*，是因为它比构造函数具有以下优势：
    (1) 构造函数的名字无意义，方法的名字包含更多有用信息
    (2) 构造函数只能返回当前Class类型对象，而方法可以返回当前类型对象、当前类型的子类对象，也可以返回基础数据类型
    (3) 如果创建过程很复杂，那么方法可以把很多不应该由构造函数处理的过程放在方法中，让构造函数只处理初始化成员的工作，职责更单一。
    (4) 方法可以控制生成对象的个数(单例，多例等)
  
  # 感想
  看了今天的内容，突然有个疑问:
  *static*方法可以是抽象方法吗？可以被继承吗？
  验证了一下，发现 *static*方法可以被重写，*static* 与 *abstract* 是冲突的, 不能同时修饰一个方法；而且，如果用子类重写了父类的static方法，这时候让父类的引用指向子类对象，然后调用该*static*方法，这时调用的是父类的*static*方法，也就是不支持“多态”，这也解释了为什么*static* 与 *abstract*冲突。
  
  关于第二题，直觉上来讲，如果不用静态方法就只能对对象方法，但使用对象方法的前提是有一个对象，但这个方法就是用来创建对象的，这时一个死锁。。。但显然问题的用意不是这个，于是查了资料。。。

  展开

  2

  13
• 
  KK

  2020-04-06

  作者只会java，感觉讲起来有些晦涩。感觉没有讲清楚，什么叫工厂模式。何为工厂？作者在讲解每一个模式的时候，是不是应该解释一下，为什么起这个名字？不同的名字，肯定是具体描述的抽象。通过名字的由来，就能够明确其相关的区别。

  1

  7
• 
  Robin

  2020-07-25

  原文：简单工厂模式的实现方法，如果我们要添加新的 parser，那势必要改动到 RuleConfigParserFactory 的代码，那这是不是违反开闭原则呢？实际上，如果不是需要频繁地添加新的 parser，只是偶尔修改一下 RuleConfigParserFactory 代码，稍微不符合开闭原则，也是完全可以接受的。
  原文：工厂方法：当我们需要添加新的规则配置解析器的时候，我们只需要创建新的 parser 类和 parser factory 类，并且在 RuleConfigParserFactoryMap 类中，将新的 parser factory 对象添加到 cachedFactories 中即可。代码的改动非常少，基本上符合开闭原则。
  感觉说法有点牵强，添加一个类，简单工厂模式修改RuleConfigParserFactory， 工厂方法也要修改RuleConfigParserFactoryMap，也是会违背开闭原则。关键简单工厂模式(第二种方式)下添加的代码量一个是map.put,工厂方法也是一个map.put,然后说明工厂方法代码的改动非常少，基本上符合开闭原则？

  展开

  作者回复: 改动是不多呀������ 您有更好的设计思路建议吗？

  6

  6
• 
  乾坤瞬间

  2020-02-21

  课后习题1，在spark livy框架中，有一个ClientFactory类，这个类根据用户的开发环境会设置成不同的客户端，一种是用来生产rpcClient客户端，一种是用来生产httpClient，每一种创建的逻辑和方式都非常复杂，会根据不同的参数生成Client,有些客户端会内置看门狗，以提高可用性，有些没有.所以应对这种创建的复杂性，使用了工厂模式，使用了工厂的工厂
  习题2，个人认为这样的静态方法，第一与单例模式的思想不可分离，因为创建对象的抽象不需要通过创建一个新的类来实现，或者根据dry选择，用静态方法复用代码块的方式更加直接粗糙，简单美。我觉得在可测试方面是有影响的，不过因为这种简单的抽象是基于原有逻辑不存在未决行为的基础上的，而且对新增的代码有足够的信心
  同时总结一下今天的三种工厂方法的演进
  利用数学公式y≡f(x,x2)的角度，y是关于x x2的一个系统描述。
  简单工厂只基于在系统y在不断加上x3的情况下，直接引入一个新的变量来简单替换f函数
  工厂函数是在替换变量的基础上对x进行了再替换，使得系统更容易理解，y≡f(θ(x),θ(x2)...)形式
  抽象方法是把x变量替换为δ(x,m)即，y≡f(δ(x,m)，δ(x2,m))形式

  展开

  

  6
• 
  失火的夏天

  2020-02-12

  对象每次都要重用，也可以用map缓存，不过value要改成全类名，通过反射来创建对象，这样每次都是一个新的类了，除非那个类被设计成禁止反射调用。

  9

  6
• 
  林子er

  2020-04-24

  工厂方法和抽象工厂都是先定义工厂接口，由子类去创建实际的对象。不同点在于每个工厂方法只负责创建一种对象，解决的是一维问题，而抽象工厂一个工厂创建一簇对象（多种），解决的是多维问题（文章中是二维）。工厂方法是抽象工厂的一种特例。抽象工厂是采用降维的思想来解决复杂问题。

  

  5
• 
  丹枫无迹

  2020-08-19

  我一直不明白工厂方法模式存在的意义，除了争哥说的，当类的实例化比较复杂时每个类的实例化单独出来，简化代码。
  
  工厂方法模式，RuleConfigSource 类中实例化工厂，再由工厂创建类，难道直接 new 个类不更简单吗？那就变成简单工厂模式了。。。工厂方法一样也破坏了开闭原则啊。
  
  

  2

  4
• 
  Wh1

  2020-04-10

  看到工厂方法模式，相信很多人会和我有一模一样的疑问：工厂方法模式不是一样存在if - else么，就算再通过一个工厂优化了if - else分支，与第二种简单工厂不是差不多么？
  反复看了几遍理解类作者的意图。如果ConfigParser的实例创建不是简单的 new 这么简单，而是存在很多复杂的逻辑，那么简单工厂模式就不能通过直接put(newConfigParser())这种方式，必须通过 if else 语句块来完成获取解析器对象的逻辑。
  如果要封装复杂的初始化逻辑，那么就可以通过工厂方法来重构。但是工厂方法重构之后会有很多if - else分支，这时候就可以再建立一个工厂将这些 if - else分支优化。
  总而言之，如果创建对象是一个简单的new 就能完成的，那么毋庸置疑简单工厂更好一些。如果创建对象比较复杂，就采用工厂方法

  展开

  1

  4
• 
  唐龙

  2020-02-12

  试着把代码翻译成了C++语言，应该算是搞懂了(以前只会单例)。目前没写过特别复杂的项目，简单工厂对我个人来说够用了。

  

  4
• 
  勤劳的明酱

  2020-02-12

  那Spring的BeanFactory实际上使用的是简单工厂模式 + 单例模式对吧，如果是工厂模式那就是使用ObjectFactory和FactoryBean来实现。第三方的复杂bean的初始化使用工厂模式，对于普通的bean统一处理，虽然复杂但没必要使用工厂。

  1

  3
• 
  杨鹏程baci

  2020-08-14

  看了很多回答，第2个问题我总感觉和大家理解的不太一样，我认为这个问题的关注点是创建对象的方法为啥是静态的。首先静态的使用更方便，可以不需要通过创建工厂类对象来调用创建对象的方法；第二点这种工具类没有其他面向对象的属性，只负责创建对象，也不需要严格通过对象来进行使用；第三点如果要创建工厂类的对象要么就会发生频繁创建和销毁对象，要么就有需要引入单例模式。用上原因通过类名来调用静态方法是最简单，最实用的方式，也符合简单原则。

  

  2
• 
  宁悦

  2020-06-09

  应用场景：根据 .json .xml .yaml后缀选择不同的解析器。生产不同对象。
  
     实现方式1.0：
          直接if-else判断，生成不同的解析器。过多的if-else判断，为了代码可读性，将代码封装到一个类中形成2.0方式。
  
     实现方式2.0：
           逻辑过于复杂抽象到一个类中，形成简单工厂模式。
  
           简单工厂：
               定义一个接口，不同的解析器继承这个接口，在Factory里面创建对象。
               把所有的判断逻辑都放在了Factory里面，
  
           每次新增后缀名，都需要修改if-else语句，为了不修改if-else语句，不违反开放-关闭规则，引入工厂方法。
     
     实现方式3.0
           工厂方法：
               把所有的if-eLse，利用多态方式解耦。
               首先创建工厂接口，然后创建工厂实现类，引用产品接口
               创建产品接口，创建产品实现类。
  
           每次新增需求，都要多写工厂类，避免过的的编写工厂类，引入抽象工厂方法。
     
     实现方式4.0
          抽象工厂方法：
              一个工厂生产多个产品。

  展开

  

  2
• 
  阿德

  2020-03-27

  在阐述工 厂方法（Factory Method）的第一段-----“ 如果我们非得要将 if 分支逻辑去掉，那该怎么办呢？比较经典处理方法就是利用多态。按照多态的实现思路，对上面的代码进行重构”，然后铮哥下面的工厂方法还是用到了跟简单工厂方法一样的多态和if else，，，看不出有代码实现原理上什么不同

  

  2