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

个人意见，传统的工厂模式太麻烦了，除非业务真的很复杂，通常我会选择以下方案。 还是举文中的例子 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可以不管，一样的道理，灵活运用。

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

传统的工厂模式确实很传统。 简单工厂是在一个工厂方法里通过流程控制语句创建不同的对象，适合创建简单的对象。 工厂方法和简单方法没有什么区别，只是用工厂对象再此封装了复杂对象的创建。工厂的工厂负责调用工厂的创建方法，每个工厂只创建一个对象，适合创建复杂的对象。 工厂模式是对创建方法的封装和抽象，创建的复杂度无法被抵消，只能被转移到工厂内部消化。

掌握了使用工厂模式的本本质：封装变化（创建逻辑可能变化）、隔离复杂性、控制复杂度（让类职责更加单一）、代码复用。 如果创建的对象不能复用，又不想用if–else，就不能使用简单工厂模式。 这个可以在static代码块中使用反射？

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

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

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

在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. 静态工厂方法可以控制创建实例的个数。例如单例模式，或者多例模式，使用本质上是可以用静态工厂方法实现。

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

一、三种工厂模式 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);