上周六的时候,大学同学来北京出差,于是就带着另一个同寝室的哥们一块到国贸那边聚了聚,各自聊了聊最近的状态,感触良多!我是android开发的,他俩是搞Java后台的!如果非特有的情况怕是很难聚到一块,同时也觉得时间是过的真快!当我出来开始做android开发的时候,系统的最新版本还是5.X,但是现在谷歌爸爸已经推出8.0的奥利奥了!回想一下,技术还是那么的渣,当时定的目标一个也没达成!囧囧囧。。。
好了,不意淫了!开撸了!
定义:定义一个用于创建对象的接口,让子类决定实例化哪一个类,工厂方法使一个类的实例化延迟到其子类。
工厂模式根据抽象的角度和层级的不同可以分为两种模式:
1.工厂方法模式 (Factory Method)
2.抽象工厂模式 (Abstract Factory)
一、工厂方法模式
工厂方法模式又可以分为:
1.简单工厂模式
2.标准工厂模式
文字的表达能力总是有限的,一千个读者,就有一千个哈姆雷特!所以,我们还是上代码吧!
(1).标准工厂模型
我们一car的车型大小为例:
car的统一接口:
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/11 15:58
* 修改人:TCX
* 修改备注:
*/
public interface ICarInterface {
void getCarType();
}
实现car接口的三种车型,分别为小,中,大:
/**
* 小车类型
*/
class SmallCar implements ICarInterface{
@Override
public void getCarType() {
Log.e("car_type","I am small car");
}
}
/**
* 中型车
*/
class MiddleCar implements ICarInterface{
@Override
public void getCarType() {
Log.e("car_type","I am middle car");
}
}
/**
* 大型车
*/
public class BigCar implements ICarInterface{
@Override
public void getCarType() {
Log.e("car_type","I am big car");
}
}
工厂接口如下:
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/11 16:08
* 修改人:TCX
* 修改备注:
*/
public interface IFactoryInterface {
ICarInterface getCarType();
}
对应的三种车型工厂:
public class SmallCarFactory implements IFactoryInterface{
@Override
public ICarInterface getCarType() {
return new SmallCar();
}
}
public class MiddleCarFactory implements IFactoryInterface {
@Override
public ICarInterface getCarType() {
return new MiddleCar();
}
}
public class BigCarFactory implements IFactoryInterface {
@Override
public ICarInterface getCarType() {
return new BigCar();
}
}
测试代码如下:
IFactoryInterface smallCarFactory=new SmallCarFactory();
IFactoryInterface middleCarFactory=new MiddleCarFactory();
IFactoryInterface bigCarFactory=new BigCarFactory();
ICarInterface small = smallCarFactory.getCarType();
ICarInterface middle=middleCarFactory.getCarType();
ICarInterface big=bigCarFactory.getCarType();
small.getCarType();
middle.getCarType();
big.getCarType();
(1).简单工厂模型
接着分析一下简单工厂模式,这是最简单的变种,也叫做静态工厂方法模式,从这个名字就可以看出工厂的方法是静态的.既然工厂方法是静态的,那么工厂就不能通过继承进行扩展,如果有新增的产品,就只能在静态方法里面做修改所以从这个角度来说简单工厂模式是不符合开闭原则的,这一点是需要注意的!
来,我们接着撸一个简单工厂模型!
public static final int SMALL_CAR=1;//小型车
public static final int MIDDLE_CAR=2;//中型车
public static final int BIG_CAR=3;//大型车
public static ICarInterface getCar(int carTypr){
ICarInterface carType=null;
switch (carTypr){
case SMALL_CAR:
carType=new SmallCar();
break;
case MIDDLE_CAR:
carType=new MiddleCar();
break;
case BIG_CAR:
carType=new BigCar();
break;
}
return carType;
}
很简单吧!如上所说,这就是标准工厂最简单的变形!!
二、抽象工厂模式
工厂模式上面写了两种形式,很明显的一个标志就是:我们将产品的共有特性提出来抽象成了一个接口,比如我们写的那个汽车的例子,从理论上来讲,它们都是汽车!至少在名字上是汽车的这个共性!但是什么是抽象的工厂模式呢?
定义:为创建一组相关或相互依赖的对象提供一个接口,而且无需指定它们的具体类。
抽象工厂模式是工厂方法模式的升级版,他俩最主要的区别就是:工厂方法模式针对的是一个产品等级结构,而抽象工厂模式针对的是多个产品结构!而在编程中,工厂方法模式提供的所有产品都是衍生自同一个接口或者抽象类,而抽象工厂模式则是衍生自不同的接口或抽象类!
光说不练假把式!我们来撸一个栗子吧!
产品一接口
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:08
* 修改人:TCX
* 修改备注:
*/
public interface IProduct1 {
void show();
}
产品二接口
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:08
* 修改人:TCX
* 修改备注:
*/
public interface IProduct2 {
void show();
}
产品一接口实现
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:09
* 修改人:TCX
* 修改备注:
*/
public class Product1 implements IProduct1 {
@Override
public void show() {
Log.e("Product1:","I am a boy!");
}
}
产品二接口实现
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:09
* 修改人:TCX
* 修改备注:
*/
public class Product2 implements IProduct2 {
@Override
public void show() {
Log.e("Product1:","I am a girl!");
}
}
工厂接口
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:11
* 修改人:TCX
* 修改备注:
*/
public interface Factory {
public IProduct1 showPeople1();
public IProduct2 showPeople2();
}
工厂实现
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 16:13
* 修改人:TCX
* 修改备注:
*/
public class FactoryImp implements Factory {
@Override
public IProduct1 showPeople1() {
return new Product1();
}
@Override
public IProduct2 showPeople2() {
return new Product2();
}
}
抽象工厂实现测试
FactoryImp factoryImp=new FactoryImp();
IProduct1 iProduct1 = factoryImp.showPeople1();
IProduct2 iProduct2 = factoryImp.showPeople2();
iProduct1.show();
iProduct2.show();
额。。撸完之后,索然无味!我们还是来点亮眼的操作吧!
需求描述:我们需要增加一个新的产品,该怎么办呢?
按照我们之前的思路:重新增加新产品的类,如果是标准的工厂方法模式,我们再新建一套工厂呗,如果是简单工厂,我们增加判断条件;再如果是抽象工厂的话,增加产品,修改工厂类!
嗯。逻辑简单,耦合度低!多符合工厂模式的特点,低耦合!
容我做个手势:
我们可以在中间加上泛型的类型强转,方法如下:
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 17:05
* 修改人:TCX
* 修改备注:
*/
public abstract class AbstractProduct {
public abstract <T extends IProduct1>T product(Class<T> clazz) throws Exception;
}
子类实现:
/**
* 类描述:
* 创建人:TCX
* 创建时间:2017/9/12 17:08
* 修改人:TCX
* 修改备注:
*/
public class SubProduct extends AbstractProduct {
@Override
public <T extends IProduct1> T product(Class<T> clazz) throws Exception {
IProduct1 iProduct1=null;
iProduct1 = (IProduct1) Class.forName(clazz.getName()).newInstance();
return (T)iProduct1;
}
}
那么,在之后修改的过程中,我们基本就直接添加新的产品,不需要对工厂进行改造了!
测试代码:
SubProduct subProduct=new SubProduct();
try {
Product1 product = subProduct.product(Product1.class);
product.show();
} catch (Exception e) {
e.printStackTrace();
}
OK,总算是唠叨完了!我的天!如果大家有疑问或者写的理解的不对的地方,欢迎大家指正,共同进步!
每天进步一点点,时间会让你成为巨人!加油!!