简单（静态）工厂模式

约定不等于承诺〃 2022-05-24 10:04 193阅读 0赞

## 简单（静态）工厂模式 ##

[观察者模式][Link 1]

## 一、背景介绍 ##

--------------------

工厂模式是设计模式的一种，设计模式是自程序开发逐渐就有的，提高开发效率的一种设计思路，先前的开发者们一直在用，只是后来这四个人出了一本书总结了下，就是现在的23种设计模式：

1994年由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人合著出版的 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）书中首次提到的，所以叫GOF

书中共有三个层面的内容：

> 一、算是一个总结性的，把程序开发过程中在不同系统中多次使用过的成功设计的模式进行总结，用名称-问题-解决方案-实用效果这几个要素来描述；

> 二、提出了面向对象开发中“针对接口编程而不是针对实现编程”，“优先使用组合而不是继承”的总体设计思路；

> 三、就是基于上面的设计思路所形成的常用的设计模式，也就是现在流传最广的23种常见的设计模式；

设计模式是为了更好的实现开发，使代码更易懂，易维护。它也是为了解决大多数开发者们的问题而出现的，当然它也不是万能的。除了设计模式我们在开发过程中还需要遵循基本的设计原则，这里后面再说。

**概念**

> 许多人通晓并且使用的经过分类的代码设计经验的总结。  
> 设计模式是开发者们在开发过程中面临一般问题的解决方案，这些解决方案是经过相当长的一段时间的试验和错误总结出来的。设计模式几乎在所有的编程里都适用。

**目的**

> 为了提高代码可重用性、可扩展性、健壮性、更容易被理解。

\*当前说的设计模式是针对面向对象,而不是面向过程

## 二、知识剖析 ##

--------------------

工厂模式

> 工厂是为了实现对构造过程（创建过程）的封装。也是设计原则的体现。工厂模式是一种创建型的设计模式，主要思想就是替代new为我们创建对象，工厂可以选择创建对象的方法，对这个构造过程（创建方法）进行选择的逻辑就是工厂模式的逻辑。 这样也是为了给以后的系统带来更大的可扩展性，实现低耦合。

工厂模式大概有三种

> 简单工厂模式  
> 工厂方法模式  
> 抽象工厂模式

简单（静态）工厂模式

> 简单工厂模式是最初自然而然就有的设计思想，它只是把创建过程比较自然的封装了一下，又称为静态工厂模式，是直接根据条件决定创建的产品。

简单工厂模式由三部分组成：

1.  工厂角色（工厂/工厂抽象类）：它创建具体产品，实现了对创建过程（构造过程）的封装。也是设计原则的体现。工厂类里面是创建对象的逻辑，也就是对这个构造过程进行封装
2.  抽象产品角色（产品抽象/接口类）：工厂类所创建的产品的父类，或者说它们的共同接口
3.  具体产品角色（产品实体类）：工厂类所创建的任何对象都是这个角色的实例

工厂模式和抽象工厂则是多了一个共同的工厂接口，所有实例工厂都是这个接口工厂的实现类

## 三、常见问题 ##

--------------------

**设计模式**

*  设计模式只是思路，并不能解决所有问题
 *  不要强制使用，它是用来解决问题，而不是寻找问题
 *  一定要在对的地方使用，不然只会适得其反

设计模式三大类：

> **1.创建型模式** ： 专注于如何初始化对象，就是在创建对象的同时隐藏创建逻辑，避免去使用new直接实例化对象  
> 模式有工厂、单例、建造者、原型模式等等  
> **2.结构型模式** ： 结构型模式是针对类和对象的组合，思想是如何组合类和对象以获得更大/更好的结构  
> 模式有桥接、适配器、装饰、委托、享元、组合模式等等  
> **3.行为型模式** ：关心的是对象之间的责任分配，它不仅仅指定结构，而且还概述了它们之间的消息传递的模式  
> 模式有命令、观察者、访问者、迭代器、中介者、策略模式等等

**设计原则**（不分先后）

**一是开闭原则**：

> 对扩展是开放的，对修改是关闭的。也就是只能添加，不能修改。比如：游戏/软件更新，只通过扩展修改，而不是更改原有的代码。

**二是LoD（迪米特）法则**：

> 一个对象尽可能对其它对象少了解，只关心自己。即尽可能少的与其它对象发生联系，尽量少依赖。或者说”只与直接的朋友通讯“。

**三是依赖倒置（DIP）原则**：

> 高层不应依赖低层模块，两者都应该依赖它们的抽象；抽象也不应该依赖细节，而是细节依赖抽象。  
> 比如A依赖B，如果需求改了，需要修改A的依赖为C的话就必须修改A的代码。大多数情况下A属于高层模块，B和C属于低层模块。依赖倒置原则就是把A依赖的B和C都实现接口F，而让A通过接口F间接的依赖B或者C，这样就会降低修改A的情况

**四是单一职责**：

> 非常简单的概述：一个类只有一个职责，它只负责份内的事。在任何时候都应该遵循它，这是所有设计原则的基础。这个也算是所有原则的基本原则。

**五是里氏替换原则**：

> 通俗的来说就是子类可以扩展父类，但不能改变父类原有的方法。（因为修改很可能会造成整个继承体系的破坏，这也是继承的风险）

**六是接口隔离原则**：

> 客户端不应该依赖它不需要的接口，一个类的依赖应该建立在最小接口上  
> 比如有一个接口I，它的实现类有两个：C和D,这时候A通过I去依赖C，B通过I依赖D.如果I对于A和B来说不是最小的接口（接口中还有其它方法），那么C和D这两个实现类就必须实现它们不需要实现的方法。比如A和B需要的都要在C里面有，这样C就会做额外的动作。这种情况就需要把I拆分为独立的几个更小的接口，然后把AC和BD都分离开来，让他们和自己需要的接口建立依赖。

**七是合成复用原则**（Composite Reuse Principle）:

> 尽量首先使用组合的方式，而不是使用继承。在面向对象设计中，如果直接继承基类，会破坏封装，因为继承将基类的实现细节暴露给子类；如果基类的实现发生改变，则子类的实现也不得不发生改变；从基类继承而来的实现是静态的，不可能在运行时发生改变，没有足够的灵活性。于是就提出了合成/聚合复用原则，也就是在实际开发设计中，尽量使用合成/聚合，不要使用类继承。

## 四、编码实战 ##

--------------------

如果要通过xml配置实现工厂就需要在maven里导入commons-io的jar包，用来读取自定义xml:

maven导入：
       
        <dependency>
          <groupId>commons-io</groupId>
          <artifactId>commons-io</artifactId>
          <version>2.4</version>
        </dependency>
    
        <dependency>
            <groupId>commons-configuration</groupId>
            <artifactId>commons-configuration</artifactId>
            <version>1.8</version>
        </dependency>

工厂类：

public class FruitFactory {
    
    
        private static Logger logger = Logger.getLogger(FruitFactory.class);
    
    
    //    通过匹配参数获取对象
        public static Fruit createFruit(String name){
            if (name.equalsIgnoreCase("Apple")){
                Fruit fruit = new Apple();
                return fruit;
            }else if (name.equalsIgnoreCase("banana")){
                Fruit fruit = new Banana();
                return fruit;
            }else if (name.equalsIgnoreCase("orange")){
                Fruit fruit = new Orange();
                return fruit;
            }else {
                logger.debug("没有这种水果");
                return null;
            }
    
        }
    //    通过匹配参数获取对象
        public static Fruit createFruitS(String name){
               switch (name){
                   case "apple":
                       Fruit apple = new Apple();
                       return apple;
                   case "banana":
                       Fruit banana = new Banana();
                       return banana;
                   case "orange":
                       Fruit orange = new Orange();
                       return orange;
                   default:
                       logger.debug("没有找到这种水果");
                       return null;
               }
        }
    
    //    通过配置文件获取对象
        public static Fruit createFruitForXML(){
            String name = "";
            Fruit fruit;
            try {
                XMLConfiguration xmlConfiguration = new XMLConfiguration("fruit.xml");
                name = xmlConfiguration.getString("fruit.name");
            } catch (ConfigurationException e) {
                logger.debug("xml文件读取错误",e);
                e.printStackTrace();
            }
            switch (name){
                   case "apple":
                       fruit = new Apple();
                       break;
                   case "banana":
                       fruit = new Banana();
                       break;
                   case "orange":
                       fruit = new Orange();
                       break;
                   default:
                       logger.debug("没有找到！");
                       fruit = null;
                       break;
               }
            return fruit;
        }
        
    //    通过反射匹配对象
        public static <T> T createFruitT(Class<T> cls){
            T t = null;
            try {
    
                t = (T) Class.forName(cls.getName()).newInstance();
    
            } catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) {
                logger.debug("Exception {}",e);
                e.printStackTrace();
            }
    
            return t;
        }
    
    }

产品接口：

public interface Fruit {
        void eat();
    }

产品实例：

public class Apple implements Fruit {
        @Override
        public void eat() {
            System.out.print("我是苹果，砸了牛顿，被乔布斯啃了一口的苹果\n");
        }
    }
    public class Banana implements Fruit {
        @Override
        public void eat() {
            System.out.print("吃香蕉，我是大香蕉，又软又甜的大香蕉\n");
        }
    }
    public class Orange implements Fruit {
        @Override
        public void eat() {
            System.out.print("我是橙子，细嫩多汁酸甜可口的橙子\n");
        }
    }

使用工厂去创建实例：

public class FactoryAction {
    
        public static void main(String[] args){
    
    //        直接使用new创建对象
            Apple apple = new Apple();
            apple.eat();
    
    //        使用工厂创建对象
    //        通过读取xml配置创建类
            Fruit fruit = FruitFactory.createFruitForXML();
            fruit.eat();
    
    //        通过匹配参数创造
            Fruit fruit1 = FruitFactory.createFruit("banana");
            fruit1.eat();
            Fruit fruit2 = FruitFactory.createFruitS("apple");
            fruit2.eat();
    
    //        通过反射
             Fruit fruit3 = FruitFactory.createFruitT(Orange.class);
             fruit3.eat();
    
        }
    
    
    }

关于xml配置：

fruit.xml配置文件，通过name获取参数生产相应的产品:
    <fruits>
        <fruit>
            <name>apple</name>
        </fruit>
    </fruits>

简单（静态）工厂模式就是这样，直接创建个工厂再去通过工厂创建，是不是感觉比起new很麻烦，我需要的东西直接去new就行了，干嘛还要去创建一个工厂，再通过工厂去创建？再说工厂不也一样需要new吗。

这就是工厂模式的设计思想体现的地方，也是创建型设计模式的一个思想。它是为了实现对构造过程的封装。也是设计原则的体现。工厂可以选择创建对象的逻辑，对这个构造过程进行选择的逻辑就是工厂。

而且现在只是一个new，如果你有现在有json对象，有String对象，有数据对象，依赖对象，每个都要new吗？如果你都使new用了那以后维护的时候需要修改怎么办？在每个new依赖对象的地方修改吗？  
还有之前我们也说了，开闭原则，不要修改原来的代码，而是添加新的。  
多加一层工厂去封装的意义就在于：

> *第一，用户并不关心这个东西是如何创造出来的，只要能用就行了。就像前面的new*  
> *第二，工厂方法是可以扩展的，不需要用户再修改自己的代码，方便以后的添加*

但是它的缺点就是如果需要新的产品就需要新建一个产品类，然后还要修改工厂类，在里面添加生产方法。但是这样就要修改已经写好的类，这也违反了开闭原则。怎么办呢，有几个办法：

*  一是使用反射，直接使用类，这样就不需要再修改工厂类，直接创建产品就能使用。
 *  一个就是使用配置文件，通过配置文件添加，这跟springIOC读取xml来创建bean的方法非常相似。

如果这两个都不想用，都有缺点（配置文件需要加载配置文件，反射又有性能损耗，比直接new要多封装很多次层），怎么办，于是就有了工厂方法模式。  
工厂方法模式不是这次讲的范围，这里就说一下，工厂方法模式就是对简单工厂也进行抽象，用父类工厂创建子类工厂，然后使用者再通过子类工厂获取到需要的对象，这样就不需要修改原有的代（工厂类）码，需要的时候创建产品model，再创建新的工厂类，直接继承工厂接口就可以了。

> 这里说的model产品什么的并不是单纯的pojo类，而是所有需要的依赖。就像面向对象，我们上班，出门需要穿衣（不出门也要穿）服穿衣服就需要有衣（这个衣服就是我们需要的依赖）服，这个衣服原先都是我们自己做，比如织毛衣，纺织布。现在交给了工厂，我们就不用去关心这个衣服用什么料子，什么样的样式

工厂就是封装了这个制作的过程拿给我们现成的依赖。  
而工厂方法是遵循单一职责原则的，就是子类工厂只负责单一产品的生产。使用者需要什么产品就用什么工厂去创建。

工厂模式看似简单，简单工厂更是只是比较自然的封装了一下，甚至算不上设计模式，严格来说抽象工厂模式才算是设计模式，但是有可能我们一辈子都用不到。简单工厂模式虽然简单，但是它是用处最多用的最广的。就拿智能机器人来说，大街上看到的点菜机器人、智能扫地机，学习机器人，它算是严格意义上来说的智能机器人吗，明显不是啊，真正的智能机器人都在小罗伯特那里啊，还有阿尔法狗啊，但是你用的到吗，大家都在用的就是最方便而又容易使用的，只要对我有用就好啦

## 五、扩展思考 ##

--------------------

简单工厂模式的优点和缺点

优点：

> 封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了和客户代码修改的可能性，更加容易扩展。

缺点：

> 工厂类的职责比较大，如果修改需求或者需要添加新产品的话除了需要创建产品类，还要修改工厂类，而且如果工厂类出现问题的话所有的客户端（使用方）都会出现问题。 但是工厂模式完美的解决了这个问题，完全遵循了开闭原则，只需要添加新的工厂类实现抽象接口就可以了。

简单提一下面向过程

> 面向过程就是一种实际的思考方式，它关心的是某个事件，某个过程：比如起床-穿衣洗漱—吃饭-上班-工作-吃饭-下班-吃饭-睡觉这个过程。面向过程就是一步一步实现这些步骤，依照顺序，先有起床-然后穿衣-洗漱再接着继续实现后面的步骤。这就是大概的面向过程的开发思想  
> 如果用面向对象可能就是抽象出一个上班族的类，然后实现这几个方法，它也一样可以实现这几个步骤，但是它的灵活性更强大，可以直接实现它的方法而不需要在意前后做了什么

## 六、参考文献 ##

--------------------

度娘/谷歌/知乎：  
工厂模式/工厂设计模式有什么用？

## 七、更多讨论 ##

--------------------

……  
A（耀琪）：与spring Ioc思想的区别  
Q：springIOC也使用了工厂模式的思想，至少可以看到使用SpringIOC完全可以避免使用new创建对象。

A（亚博）：在任务中 你是否使用了这种思想：  
Q：在springIOC中有类似通过xml配置文件的方式（也就是bean注入）获取实例，跟工厂方式非常相似。

[Link 1]: https://www.cnblogs.com/meijsuger/p/11433727.html