简单工厂模式、工厂模式、抽象工厂模式

一、简单工厂模式

不用设计模式并非不可以，但是用好设计模式能帮助我们更好地解决实际问题，设计模式最重要的是解耦。设计模式天天都在用，但自己却无感知。主要是学习设计模式是如何总结经验的，把经验为自己所用。学设计模式也是锻炼将业务需求转换技术实现的一种非常有效的方式。

简单工厂模式（Simple Factory Pattern）是指由一个工厂对象决定创建出哪一种产品类的实例，但它不属于 GOF，23 种设计模式简单工厂适用于工厂类负责创建的对象较少的场景，且客户端只需要传入工厂类的参数，对于如何创建对象的逻辑不需要关心。属于创建型设计模式。

 

例子：

如上类图，ICourse是课程类接口，有录制课程发方法，pythonCourse和javaCourse实现了该课程类接口 。CourseFactory是工厂类，传入字节码通过反射创建课程类。代码如下：

public class CourseFactory {
    public ICourse create(Class<? extends ICourse> clazz) {

        try {
            if (clazz != null) {
                return clazz.newInstance();
            }
        } catch (InstantiationException e) {
            e.printStackTrace();
        } catch (IllegalAccessException e) {
            e.printStackTrace();
        }
        return null;
    }
}

public interface ICourse {

    /**
     * 录制视频
     */
    void record();
}

public class JavaCourse implements ICourse {
    public void record() {
        System.out.println("录制java课程视频");
    }
}

public class PythonCourse implements ICourse {
    public void record() {
        System.out.println("python课程录制视频");
    }
}

public class Test {

    public static void main(String[] args) {
        CourseFactory factory = new CourseFactory();
        ICourse course = factory.create(JavaCourse.class);
        course.record();
    }
}

工程目录与输出

简单工厂模式在 JDK 源码也是无处不在，现在我们来举个例子，例如 Calendar 类，看Calendar.getInstance()方法，下面打开的是 Calendar 的具体创建类：

private static Calendar createCalendar(TimeZone zone,
                                           Locale aLocale)
    {
        CalendarProvider provider =
            LocaleProviderAdapter.getAdapter(CalendarProvider.class, aLocale)
                                 .getCalendarProvider();
        if (provider != null) {
            try {
                return provider.getInstance(zone, aLocale);
            } catch (IllegalArgumentException iae) {
                // fall back to the default instantiation
            }
        }

        Calendar cal = null;

        if (aLocale.hasExtensions()) {
            String caltype = aLocale.getUnicodeLocaleType("ca");
            if (caltype != null) {
                switch (caltype) {
                case "buddhist":
                cal = new BuddhistCalendar(zone, aLocale);
                    break;
                case "japanese":
                    cal = new JapaneseImperialCalendar(zone, aLocale);
                    break;
                case "gregory":
                    cal = new GregorianCalendar(zone, aLocale);
                    break;
                }
            }
        }
        if (cal == null) {
            // If no known calendar type is explicitly specified,
            // perform the traditional way to create a Calendar:
            // create a BuddhistCalendar for th_TH locale,
            // a JapaneseImperialCalendar for ja_JP_JP locale, or
            // a GregorianCalendar for any other locales.
            // NOTE: The language, country and variant strings are interned.
            if (aLocale.getLanguage() == "th" && aLocale.getCountry() == "TH") {
                cal = new BuddhistCalendar(zone, aLocale);
            } else if (aLocale.getVariant() == "JP" && aLocale.getLanguage() == "ja"
                       && aLocale.getCountry() == "JP") {
                cal = new JapaneseImperialCalendar(zone, aLocale);
            } else {
                cal = new GregorianCalendar(zone, aLocale);
            }
        }
        return cal;
    }

还有一个大家经常使用的 logback，我们可以看到 LoggerFactory 中有多个重载的方法getLogger()：

public static Logger getLogger(String name) {
ILoggerFactory iLoggerFactory = getILoggerFactory();
return iLoggerFactory.getLogger(name);
}
public static Logger getLogger(Class clazz) {
return getLogger(clazz.getName());
}

 二、工厂模式

         工厂方法模式（Fatory Method Pattern）是指定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行。在工厂方法模式中用户只需要关心所需产品对应的工厂，无须关心创建细节，而且加入新的产品符
合开闭原则。
         工厂方法模式主要解决产品扩展的问题，在简单工厂中，随着产品链的丰富，如果每个课程的创建逻辑有区别的话，工厂的职责会变得越来越多，有点像万能工厂，并不便于维护。根据单一职责原则我们将职能继续拆分，专人干专事。Java 课程由 Java 工厂创建，Python 课程由 Python 工厂创建，对工厂本身也做一个抽象。来看代码：

如上图，课程接口下面实现了java课程与python课程，课程工厂下面实现了java课程工厂与python课程工厂。如果有课程类扩展，需要实现课程工厂创建对应的课程工厂，创建课程实现课程类。

a、工厂及其它的实现

public interface ICourseFactory {
    /**
     * 创建工厂
     *
     * @return ICourse
     */
    ICourse create();
}

public class JavaCourse implements ICourse {
    public void record() {
        System.out.println("录制java课程视频");
    }
}

public class PythonCourse implements ICourse {
    public void record() {
        System.out.println("python课程录制视频");
    }
}

b、课程及其它的实现

public interface ICourse {

    /**
     * 录制视频
     */
    void record();
}

public class JavaCourseFactory implements ICourseFactory {
    public ICourse create() {
        return new JavaCourse();
    }
}

public class PythonCourseFactory implements ICourseFactory {
    public ICourse create() {
        return new PythonCourse();
    }
}

c、测试结果与工程目录

public class Test {

    public static void main(String[] args) {
        ICourseFactory factory = new JavaCourseFactory();
        factory.create().record();
    }
}

 再来看看 logback 中工厂方法模式的应用，看看类图就 OK 了

 

工厂方法适用于以下场景：
1、创建对象需要大量重复的代码。
2、客户端（应用层）不依赖于产品类实例如何被创建、实现等细节。
3、一个类通过其子类来指定创建哪个对象。
工厂方法也有缺点：
1、类的个数容易过多，增加复杂度。
2、增加了系统的抽象性和理解难度。

三、抽象工厂模式

抽象工厂模式（Abastract Factory Pattern）是指提供一个创建一系列相关或相互依赖，对象的接口，无须指定他们具体的类。客户端（应用层）不依赖于产品类实例如何被创建、实现等细节，强调的是一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量重复的代码。需要提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。

学习抽象工厂之前，我们要了解两个概念产品等级结构和产品族，看下面的图：

从上图中看出有正方形，圆形和菱形三种图形，相同颜色深浅的就代表同一个产品族，相同形状的代表同一个产品等级结构。同样可以从生活中来举例，比如，美的电器生产多种家用电器。那么上图中，颜色最深的正方形就代表美的洗衣机、颜色最深的圆形代表美的空调、颜色最深的菱形代表美的热水器，颜色最深的一排都属于美的品牌，都是美的电器这个产品族。再看最右侧的菱形，颜色最深的我们指定了代表美的热水器，那么第二排颜色稍微浅一点的菱形，代表海信的热水器。同理，同一产品结构下还有格力热水器，格力空调，格力洗衣机。产品族是具体工厂生产的产品。

下面还是以课程为例，第三期课程有了新的标准，每个课程不仅要提供课程的录播视频，而且还要提供老师的课堂笔记。相当
于现在的业务变更为同一个课程不单纯是一个课程信息，要同时包含录播视频、课堂笔记甚至还要提供源码才能构成一个完整的课程。在产品等级中增加两个产品 IVideo 录播视频和 INote 课堂笔记。

如上类图：java课程工厂与python课程工厂继承抽象类课程 工厂，java课程类与python课程类同时实现了IVideo与INode接口。

先看抽象工厂与具体工厂代码：

public abstract class AbstractCourseFactory {

    public void init() {
        System.out.println("初始化数据。。。");
    }

    public abstract INode createEdit();

    public abstract IVideo createRecord();
}

public class JavaCourseFactory extends AbstractCourseFactory {
    @Override
    public INode createEdit() {
        super.init();
        return new JavaNode();
    }

    @Override
    public IVideo createRecord() {
        super.init();
        return new JavaVideo();
    }
}

public class PythonCourseFactory extends AbstractCourseFactory {

    @Override
    public INode createEdit() {
        super.init();
        return new PythonNode();
    }

    @Override
    public IVideo createRecord() {
        super.init();
        return new PythonVideo();
    }
}

笔记业务接口与实现：

public interface INode {

    void edit();
}

public class JavaNode implements INode {
    @Override
    public void edit() {
        System.out.println("做java笔记");
    }
}

public class PythonNode implements INode {
    @Override
    public void edit() {
        System.out.println("做python笔记");
    }
}

录屏业务与实现：

public interface IVideo {

    void record();
}

public class JavaVideo implements IVideo {
    @Override
    public void record() {
        System.out.println("录制java视频");
    }
}

public class PythonVideo implements IVideo {
    @Override
    public void record() {
        System.out.println("录制python视频");
    }
}

输出结果与项目目录：

public class Test {

    public static void main(String[] args) {
        JavaCourseFactory factory = new JavaCourseFactory();

        factory.createEdit().edit();
        factory.createRecord().record();
    }
}

 

上面的代码完整地描述了两个产品族 Java 课程和 Python 课程，也描述了两个产品等级视频和手记。抽象工厂非常完美清晰地描述这样一层复杂的关系。但是，不知道大家有没有发现，如果我们再继续扩展产品等级，将源码 Source 也加入到课程中，那么我们的
代码从抽象工厂，到具体工厂要全部调整，很显然不符合开闭原则。因此抽象工厂也是有缺点的：
1、规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口。
2、增加了系统的抽象性和理解难度。

 

但在实际应用中，我们千万不能犯强迫症甚至有洁癖。在实际需求中产品等级结构升级是非常正常的一件事情。我们可以根据实际情况，只要不是频繁升级，可以不遵循开闭原则。代码每半年升级一次或者每年升级一次又有何不可呢？

利用工厂模式重构的实践案例
JDBC 操作案例，我们每次操作是不是都需要重新创建数据库连接，每次创建其实都非常耗费性能，消耗业务调用时间。我们利用工厂模式，将数据库连接预先创建好放到容器中缓存着，在业务调用时就只需现取现用。

总结：简单工厂是产品的工厂，创建系统所需要的类；工厂方法是工厂的工厂，创建其他的工厂；抽象工厂是复杂产品的工厂，不符合开闭原则。