工厂模式的历史由来
在现实生活中我们都知道,原始社会自给自足(没有工厂)、农耕社会小作坊(简单工 厂,民间酒坊)、工业革命流水线(工厂方法,自产自销)、现代产业链代工厂(抽象工厂, 富士康)。 我们的项目代码同样也是由简而繁一步一步迭代而来,但对于调用者来说确是越来越简单化。一、工厂模式是什么?
工厂顾名思义就是创建产品,根据产品是具体产品还是具体工厂可分为简单工厂模式和工厂方法模式,根据工厂的抽象程度可分为工厂方法模式和抽象工厂模式。该模式用于封装和管理对象的创建,是一种创建型模式。
二、如何实现工厂模式
1、简单工厂模式
简单工厂模式(Simple Factory Pattern)是指由一个工厂对象决定创建出哪一种产品 类的实例,但它不属于 GOF的23 种设计模式(参考资料: http://en.wikipedia.org/wiki/Design_Patterns#Patterns_by_Type)。简单工厂适用 于工厂类负责创建的对象较少的场景,且客户端只需要传入工厂类的参数,对于如何创建对象的逻辑不需要关心。
代码实现如下,我们可以先定义一个课程标准 ICourse 接口:
:
public interface ICourse {
/ * * 录制视频 * /
public void record();
}
创建一个 Java 课程的实现 JavaCourse 类:
public class JavaCourse implements ICourse {
public void record() {
System.out.println("录制 Java 课程");
}
}
看客户端调用代码,我们会这样写:
public static void main(String[] args) {
ICourse course = new JavaCourse();
course.record();
}
看上面的代码,父类 ICourse 指向子类 JavaCourse 的引用,应用层代码需要依赖 JavaCourse,如果业务扩展,我继续增加 PythonCourse 甚至更多,那么我们客户端 的依赖会变得越来越臃肿。因此,我们要想办法把这种依赖减弱,把创建细节隐藏。虽 然目前的代码中,我们创建对象的过程并不复杂,但从代码设计角度来讲不易于扩展。 现在,我们用简单工厂模式对代码进行优化。先增加课程PythonCourse 类:
public class PythonCourse implements ICourse {
public void record() {
System.out.println("录制 Python 课程");
}
}
创建 CourseFactory 工厂类:
public class CourseFactory {
public ICourse create(String name){
if("java".equals(name)){
return new JavaCourse();
}else if("python".equals(name)){
return new PythonCourse();
}else{
return null;
}
}
}
修改客户端调用代码:
public class SimpleFactoryTest {
public static void main(String[] args) {
CourseFactory factory = new CourseFactory();
factory.create("java");
}
}
客户端调用是简单了,但如果我们业务继续扩展,要增加前端课程,那么工厂中的 create() 就要根据产品链的丰富每次都要修改代码逻辑。不符合开闭原则。因此,我们 对简单工厂还可以继续优化,可以采用反射技术:
public class CourseFactory {
public ICourse create(String className){
try {
if (!(null == className || "".equals(className))) {
return (ICourse) Class.forName(className).newInstance();
}
}catch (Exception e){
e.printStackTrace();
}
return null;
}
}
修改客户端调用代码:
public static void main(String[] args) {
CourseFactory factory = new CourseFactory();
ICourse course =factory.create("com.gupaoedu.vip.pattern.factory.simplefactory.JavaCourse");
course.record();
}
优化之后,产品不断丰富不需要修改 CourseFactory 中的代码。但是,有个问题是, 方法参数是字符串,可控性有待提升,而且还需要强制转型。我们再修改一下代码
public ICourse create(Class<? extends ICourse> clazz){
try {
if (null != clazz) {
return clazz.newInstance();
}
}catch (Exception e){
e.printStackTrace();
}
return null;
}
优化客户端代码:
public static void main(String[] args) {
CourseFactory factory = new CourseFactory();
ICourse course = factory.create(JavaCourse.class);
course.record();
}
简单工厂也有它的缺点:工厂类的职责相对过重,不易于扩展过于复杂的产品结构。所以我们引入工厂方法模式。
2、工厂方法模式
工厂方法模式(Fatory Method Pattern)是指定义一个创建对象的接口,但让实现这 个接口的类来决定实例化哪个类,工厂方法让类的实例化推迟到子类中进行。在工厂 方法模式中用户只需要关心所需产品对应的工厂,无须关心创建细节,而且加入新的 产品符合开闭原则。
工厂方法模式主要解决产品扩展的问题,在简单工厂中,随着产品链的丰富,如果每个 课程的创建逻辑有区别的话,工厂的职责会变得越来越多,有点像万能工厂,并不便于 维护。根据单一职责原则我们将职能继续拆分,专人干专事。Java 课程由 Java 工厂 创建, Python 课程由 Python 工厂创建,对工厂本身也做一个抽象。
来看代码,先创建 ICourseFactory 接口:
public interface ICourseFactory {
ICourse create();
}
在分别创建子工厂,JavaCourseFactory 类:
import com.cc.vip.pattern.factory.ICourse;
import com.cc.vip.pattern.factory.JavaCourse;
public class JavaCourseFactory implements ICourseFactory {
public ICourse create() {
return new JavaCourse();
}
}
PythonCourseFactory 类:
import com.cc.vip.pattern.factory.ICourse; import
com.gupaoedu.vip.pattern.factory.PythonCourse;
public class PythonCourseFactory implements ICourseFactory {
public ICourse create() {
return new PythonCourse();
}
}
看测试代码:
public static void main(String[] args) {
ICourseFactory factory = new PythonCourseFactory();
ICourse course = factory.create();
course.record();
factory = new JavaCourseFactory(); 、
course = factory.create();
course.record();
}
工厂方法适用于以下场景:
1、创建对象需要大量重复的代码。
2、客户端(应用层)不依赖于产品类实例如何被创建、实现等细节。
3、一个类通过其子类来指定创建哪个对象。
工厂方法也有缺点:
1、类的个数容易过多,增加复杂度。
2、增加了系统的抽象性和理解难度。
3、抽象工厂模式
抽象工厂模式(Abastract Factory Pattern)是指提供一个创建一系列相关或相互依赖 对象的接口,无须指定他们具体的类。客户端(应用层)不依赖于产品类实例如何被创
建、实现等细节,强调的是一系列相关的产品对象(属于同一产品族)一起使用创建对
象需要大量重复的代码。需要提供一个产品类的库,所有的产品以同样的接口出现,从而使客户端不依赖于具体实现。
抽象工厂也是有缺点的:
1、规定了所有可能被创建的产品集合,产品族中扩展新的产品等级困难,需要修改抽象工
厂的接口。
2、增加了系统的抽象性和理解难度。
但在实际应用中,我们千万不能犯强迫症甚至有洁癖。在实际需求中产品等级结构升级 是非常正常的一件事情。我们可以根据实际情况,只要不是频繁升级,可以不遵循开 闭原则。代码每半年升级一次或者每年升级一次又有何不可呢?