部分引用:https://www.cnblogs.com/wangenxian/p/10787785.html
为什么使用工厂模式
- 工厂模式是为了解耦:把对象的创建和使用的过程分开。就是Class A 想调用 Class B ,那么A只是调用B的方法,而至于B的实例化,就交给工厂类。
- 工厂模式可以降低代码重复。如果创建对象B的过程都很复杂,需要一定的代码量,而且很多地方都要用到,那么就会有很多的重复代码。我们可以这些创建对象B的代码放到工厂里统一管理。既减少了重复代码,也方便以后对B的创建过程的修改维护。由于创建过程都由工厂统一管理,所以发生业务逻辑变化,不需要找到所有需要创建B的地方去逐个修正,只需要在工厂里修改即可,降低维护成本。同理,想把所有调用B的地方改成B的子类B1,只需要在对应生产B的工厂中或者工厂的方法中修改其生产的对象为B1即可,而不需要找到所有的new B()改为new B1()。
- 工厂管理了对象的创建逻辑,使用者并不需要知道具体的创建过程,只管使用即可,减少了使用者因为创建逻辑导致的错误。
- 在日常开发中,凡是需要生成复杂对象的地方,都可以尝试考虑使用工厂模式来代替。复杂对象指的是类的构造函数参数过多等对类的构造有影响的情况。
实现方式
按实际业务场景划分,工厂模式有 3 种不同的实现方式,分别是简单工厂模式、工厂方法模式和抽象工厂模式。
简单工厂
简介:简单工厂模式属于类的创建型模式,又叫做静态工厂模式。通过专门创建一个类来负责创建其他类的实例,被创建的实例通常都具有共同的父类。
应用场景:对于产品种类相对较少的情况,考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数,不需要关心如何创建对象的逻辑,可以很方便地创建所需产品。
包含的角色及其职责:
- 工厂角色。
简单工厂模式的核心,它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用,创建所需的产品对象。 - 抽象角色。
简单工厂模式所创建的所有对象的父类,它负责描述所有实例所共有的公共接口。 - 具体产品角色。
简单工厂模式所创建的具体实例对象。
代码分析:
//设备,抽象角色
public interface Device {
public void get();
}
//冰箱,具体产品角色
public class Refrigerator implements Device{
@Override
public void get() {
System.out.println("获取冰箱");
}
}
//电视,具体产品角色
public class Television implements Device {
@Override
public void get() {
System.out.println("获取电视");
}
}
//创建工厂类生成实例,工厂角色
public class DeviceFactory {
public static Device getDevice(String device) throws IllegalAccessException, InstantiationException {
Device result = null;
if(device.equalsIgnoreCase("television")){
result = Television.class.newInstance();
}else if(device.equalsIgnoreCase("refrigerator")){
result = Refrigerator.class.newInstance();
}else{
System.out.println("没有实例化数据");
}
return result;
}
//测试
public static void main(String[] args) throws InstantiationException, IllegalAccessException {
Device device = DeviceFactory.getDevice("television");
device.get();
Device refrigerator = DeviceFactory.getDevice("refrigerator");
refrigerator.get();
}
}
优点:
工厂类是这个模式的关键,它包含必要的判断逻辑,能根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。
缺点:
工厂类包揽了所有类的实例创建工作,不太符合软件工程中说的”高内聚“的原则。工厂类要对输入参数进行相应的判断,所以扩展性不好。如果新加烤箱类,则需要重新修改工厂类的逻辑代码。
工厂方法模式
“工厂方法模式”是对简单工厂模式的进一步抽象化,其好处是可以使系统在不修改原来代码的情况下引进新的产品,即满足开闭原则。
应用场景:客户只知道创建产品的工厂名,而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。创建对象的任务由多个具体子工厂中的某一个完成,而抽象工厂只提供创建产品的接口。客户不关心创建产品的细节,只关心产品的品牌。
主要角色:
抽象工厂(Abstract Factory):提供了创建产品的接口,调用者通过它访问具体工厂的工厂方法 newProduct() 来创建产品。
具体工厂(ConcreteFactory):主要是实现抽象工厂中的抽象方法,完成具体产品的创建。
抽象产品(Product):定义了产品的规范,描述了产品的主要特性和功能。
具体产品(ConcreteProduct):实现了抽象产品角色所定义的接口,由具体工厂来创建,它同具体工厂之间一一对应。
代码分析:
//设备,抽象角色
public interface Device {
public void get();
}
//冰箱,具体产品角色
public class Refrigerator implements Device{
@Override
public void get() {
System.out.println("获取冰箱");
}
}
//电视,具体产品角色
public class Television implements Device {
@Override
public void get() {
System.out.println("获取电视");
}
}
//抽象工厂
public interface DeviceFactory {
public Device getDevice();
}
//冰箱工厂,具体工厂
public class RefrigeratorFactory implements DeviceFactory{
@Override
public Device getDevice() {
return new Refrigerator();
}
}
//电视工厂,具体工厂
public class TelevisionFactory implements DeviceFactory{
@Override
public Device getDevice() {
return new Television();
}
}
//测试
public class Test {
public static void main(String[] args) {
//获取冰箱工厂
RefrigeratorFactory refrigeratorFactory = new RefrigeratorFactory();
Device device = refrigeratorFactory.getDevice();
device.get();
//获取电视工厂
TelevisionFactory televisionFactory = new TelevisionFactory();
Device device1 = televisionFactory.getDevice();
device1.get();
}
}
优点:
用户只需要知道具体工厂的名称就可得到所要的产品,无须知道产品的具体创建过程。
灵活性增强,对于新产品的创建,只需多写一个相应的工厂类。
典型的解耦框架。高层模块只需要知道产品的抽象类,无须关心其他实现类,满足迪米特法则、依赖倒置原则和里氏替换原则。
缺点:
类的个数容易过多,增加复杂度
增加了系统的抽象性和理解难度
抽象产品只能生产一种产品,此弊端可使用抽象工厂模式解决。
理解:
简单工厂模式,如果要增加一个具体角色,需要去修改工厂类的逻辑代码,比较复杂。而工厂方法模式新增一个具体角色只需去创建两个类去实现两个接口,不用修改原来的代码。耦合度大大降低。
抽象工厂模式
抽象工厂模式是所有形态的工厂模式中最为抽象和最其一般性的。抽象工厂模式可以向客户端提供一个接口,使得客户端不必指定产品的具体类型的情况下,能够创建多个产品族的产品对象。
工厂方法模式中考虑的是一类产品的生产,如畜牧场只养动物、电视机厂只生产电视机、计算机软件学院只培养计算机软件专业的学生等。
也就是说:工厂方法模式只考虑生产同等级的产品,但是在现实生活中许多工厂是综合型的工厂,能生产多等级(种类) 的产品,如农场里既养动物又种植物,电器厂既生产电视机又生产洗衣机或空调,大学既有软件专业又有生物专业等。
应用场景:
当需要创建的对象是一系列相互关联或相互依赖的产品族时,如电器工厂中的电视机、洗衣机、空调等。
系统中有多个产品族,但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。
系统中提供了产品的类库,且所有产品的接口相同,客户端不依赖产品实例的创建细节和内部结构。
代码分析:
//抽象角色
public interface Device {
public void get();
}
//抽象冰箱类
public abstract class Refrigerator implements Device{
@Override
public abstract void get();
}
//抽象电视类
public abstract class Television implements Device {
@Override
public abstract void get();
}
//品牌一冰箱
public class Refrigerator01 extends Refrigerator {
@Override
public void get() {
System.out.println("品牌一冰箱");
}
}
//品牌二冰箱
public class Refrigerator02 extends Refrigerator {
@Override
public void get() {
System.out.println("品牌二冰箱");
}
}
//品牌一电视
public class Television01 extends Television {
@Override
public void get() {
System.out.println("品牌一电视");
}
}
//品牌二电视
public class Television02 extends Television {
@Override
public void get() {
System.out.println("品牌二电视");
}
}
//抽象工厂
public interface DeviceFactory {
//获取冰箱
public Device getRefrigerator();
//获取电视
public Device getTelevision();
}
//品牌一生产工厂
public class RefrigeratorFactory01 implements DeviceFactory{
//获取品牌一的冰箱
@Override
public Device getRefrigerator() {
return new Refrigerator01();
}
//获取品牌一的电视
@Override
public Device getTelevision() {
return new Television01();
}
}
//品牌二生产工厂
public class RefrigeratorFactory02 implements DeviceFactory {
//获取品牌二的冰箱
@Override
public Device getRefrigerator() {
return new Refrigerator02();
}
//获取品牌二的电视
@Override
public Device getTelevision() {
return new Television02();
}
}
//测试
public class Test {
public static void main(String[] args) {
//工厂01
RefrigeratorFactory01 refrigeratorFactory01 = new RefrigeratorFactory01();
Device refrigerator1 = refrigeratorFactory01.getRefrigerator();
Device television1 = refrigeratorFactory01.getTelevision();
refrigerator1.get();
television1.get();
//工厂02
RefrigeratorFactory02 refrigeratorFactory02 = new RefrigeratorFactory02();
Device refrigerator2 = refrigeratorFactory02.getRefrigerator();
Device television2 = refrigeratorFactory02.getTelevision();
refrigerator2.get();
television2.get();
}
}
结果
品牌一冰箱
品牌一电视
品牌二冰箱
品牌二电视
关系图如下所示:
优缺点:
抽象工厂模式的扩展有一定的“开闭原则”倾斜性:
当增加一个新的产品族时只需增加一个新的具体工厂,不需要修改原代码,满足开闭原则。
当产品族中需要增加一个新种类的产品时,则所有的工厂类都需要进行修改,不满足开闭原则。