设计模式沉思录（一）之工厂模式

2018-07-12 原理理解 PV:

设计模式沉思录（一）之工厂模式

本文整理自四人帮著作：Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素）

设计模式的六大原则

1、开闭原则（Open Close Principle）

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔（即便是带电也能部署）的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，关键部分是需要使用接口和抽象类。

2、里氏代换原则（我称之为父子原则）（Liskov Substitution Principle）

里氏代换原则是面向对象设计的基本原则之一。里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则（Dependence Inversion Principle）

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则（Interface Segregation Principle）

这个原则的意思是：使用多个隔离的接口（抽象出更多更具体的接口配合，而不是一个啥都能干的接口），比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、迪米特法则，又称最少知道原则（Demeter Principle）

最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

模式分类

23 种设计模式分为三大类：创建型模式（Creational Patterns）、结构型模式（Structural Patterns）、行为型模式（Behavioral Patterns）。

创建型模式（Creational Patterns）

这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用 new 运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。

工厂模式

工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。
在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。

意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。

主要解决：主要解决接口选择的问题。
何时使用：我们明确地计划不同条件下创建不同实例时。
如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。
关键代码：创建过程在其子类执行。
应用实例： 1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。

优点：
1、一个调用者想创建一个对象，只要知道其名称就可以了。并且不用设置属性。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。

缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。

使用场景：
1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。
2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3、设计一个连接服务器的框架，需要三个协议，”POP3”、”IMAP”、”HTTP”，可以把这三个作为产品类，共同实现一个接口。

注意事项：
不要滥用工厂模式：在任何需要生成复杂对象的地方，都可以使用工厂方法模式。而简单对象，特别是只需要通过 new 就可以完成创建的对象，因为如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

实现：
我们将创建一个 Shape 接口和实现 Shape 接口的实体类。下一步是定义工厂类 ShapeFactory。
此处输入图片的描述

FactoryPatternDemo，我们的演示类使用 ShapeFactory 来获取 Shape 对象。它将向 ShapeFactory 传递信息（CIRCLE / RECTANGLE / SQUARE），以便获取它所需对象的类型。

1.产品接口（Shape形状）

1
2
3

public interface Shape {
   void draw();
}

2.实现产品接口的实体类,这里只列出Rectangle，Square和Circle同理

public class Rectangle implements Shape {
 
   @Override
   public void draw() {
      System.out.println("Inside Rectangle::draw() method.");
   }
}

3.工厂类，根据信息来生产不同的产品

public class ShapeFactory {
    
   //使用 getShape 方法,利用反射机制，通过类对象获取形状类型的对象
   public <T extends Shape> T getShape(Class<T> shapeType){
      
        try {
            return shapeType.newInstance();//利用反射返回一个对应的shape实例
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }
}

4.使用该工厂类，通过传递类型信息来获取实体类的对象。

public class FactoryPatternDemo {
 
   public static void main(String[] args) {
      ShapeFactory shapeFactory = new ShapeFactory();
 
      //获取 Circle 的对象，并调用它的 draw 方法
      shapeFactory.getShape("CIRCLE").draw();
 
      //获取 Rectangle 的对象，并调用它的 draw 方法
      Shape shape2 = shapeFactory.getShape("RECTANGLE").draw();
 
      //获取 Square 的对象，并调用它的 draw 方法
      Shape shape3 = shapeFactory.getShape("SQUARE").draw();
   }
}

总结：
通过使用工厂类，产品类被屏蔽，高层模块中只知道产品类的接口，而不需要对产品有过多的了解。这符合我们面向抽象编程的原则。符合迪米特法则（少知道）。也符合里氏替换（父子）原则。

工厂方法模式在实际中应用十分广泛，举个简单的例子。我们在用jdbc进行数据库连接的时候，我们获取连接的时候用的getConnection方法直接获取，而不用了解具体的获取过程。当数据库从oracle变成mysql的时候。我们写的数据库的操作语句根本不用变化。因为底层的数据库连接获取被jdbc屏蔽了。这就是一个工厂方法模式的典型应用。

工厂方法模式有很多扩展，也可以和其他的很多模式进行结合使用。比如在上面的这个例子中。由于只有一个工厂，我们没必要将其实例化，也没必要在增加一个工厂接口。像这样的简单的情况。我们可以直接将工厂接口删除掉，然后把工厂中创建类的方法声明为静态方法。直接通过静态方法进行创建对象调用就可以，这种对一般工厂方法模式的缩小，我们称之为简单工厂模式。

这种模式的应用也十分广泛。在某个项目比较复杂时候，如果实例化一个产品很复杂，如果将所有的实例化过程都写到同一个工厂中，那么该工厂的实例化部分将会显得十分臃肿。这样的情况下。我们可以声明多个工厂类，实现工厂接口，每个工厂类对应着不同的产品的实例化。另外，工厂方法模式也可以直接代替单例模式进行使用，我们会在单例模式中具体的进行阐述。