工厂方法模式简单介绍
工厂方法模式是建立型设计模式之一。工厂方法模式是一种结构简单的模式，其在咱们平时开发中应用很普遍。如 Android 中的 Activity 里的各个生命周期方法，以 onCreate 方法为例，它就能够看做是一个工厂方法，咱们在其中能够构造咱们的 View 并经过 setContentView 返回给 framework 处理等。java
工厂方法模式的定义
定义一个用于建立对象的接口，让子类决定实例化那个类web
工厂方法模式的使用场景
在任何须要生成复杂对象的地方，均可以使用工厂方法模式。复杂对象适合使用工厂模式，用 new 就能够完成建立的对象无需使用工厂模式。设计模式
工厂方法模式的 UML 类图
角色介绍：架构
Factory：抽象工厂，其为工厂方法模式的核心；
ConcreteFactory：具体工厂，其实现了具体的业务逻辑；
Product：抽象产品，是工厂方法模式所建立的产品的父类；
ConcreteProduct：具体产品，为实现抽象产品的某个具体产品的对象。
其实经过上面的 UML 类图，咱们能够得出一套 工厂方法模式的通用代码：ide
//抽象产品类
public abstract class Product {
/**
* 产品类的抽象方法，由具体的产品类去实现
*/
public abstract void method();
}
//具体产品类A
public class ConcreteProductA extends Product {
@Override
public void method() {
Log.d("Product","我是具体的产品A");
}
}
//具体产品类B
public class ConcreteProductB extends Product {
@Override
public void method() {
Log.d("Product","我是具体的产品B");
}
}
//抽象工厂
public abstract class Factory {
/**
* 抽象工厂方法，具体生产什么产品由子类去实现
*@return
*/
public abstract Product createProduct();
}
//具体工厂类
public class ConcreteFactory extends Factory {
@Override
public Product createProduct() {
return new ConcreteProduct();
}
}
//客户类
public class Client {
public static void main(){
Factory factory = new ConcreteFactory();
Product product = factory.createProduct();
product.method();
}
}
上述的代码中咱们在 Client 类中构造了一个工厂对象，并经过其生产了一个产品对象，这里咱们获得的产品对象是 ConcreteProductA 的实例，若是想获得 ConcreteProductB 的实例，更改 ConcreteFactory 中的逻辑便可：svg
//具体工厂类
public class ConcreteFactory extends Factory {
@Override
public Product createProduct() {
// return new ConcreteProductA();
return new ConcreteProductB();
}
}
这种方式比较常见，须要哪个产品就生产哪个，有时候也能够利用反射的方式更简洁地来生产具体产品对象，此时，须要在工厂方法的参数列表中传入一个 Class 类来决定是哪个产品类：spa
//抽象工厂
public abstract class Factory {
/**
* 抽象工厂方法，具体生产什么产品由子类去实现
*
*@return
*/
public abstract T createProduct(Class clazz);
}
//具体工厂类
public class ConcreteFactory extends Factory {
@Override
public T createProduct(Class clazz) {
Product p = null;
try {
p = (Product) Class.forName(clazz.getName()).newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return (T) p;
}
}
最后再来看看 Client 中的实现：设计
//客户类
public class Client {
public static void main() {
Factory factory = new ConcreteFactory();
Product product = factory.createProduct(ConcreteProductB.class);
product.method();
}
}
须要哪个类的对象就传入哪个类的类型便可，这种方法比较简洁、动态。code
当咱们的工厂只有一个的时候，咱们仍是为工厂提供了一个抽象类，那么，咱们是否能够将其简化掉呢？若是肯定你的工厂类只有一个，那么简化掉抽象类是没有问题的，咱们只须要将对应的工厂方法改成静态方法便可：xml
//具体工厂类
public class Factory{
@Override
public static T createProduct(Class clazz) {
Product p = null;
try {
p = (Product) Class.forName(clazz.getName()).newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return (T) p;
}
}
向这样的方式又称为简单工厂模式或静态工厂模式，它是工厂方法模式的一个弱化版本。
其实到这里你们应该能够发现，工厂方法模式是彻底符合设计原则的，其下降了对象之间的耦合度，并且，工厂方法模式依赖于抽象的架构，其将实例化的任务交由子类去完成，有很是好的扩展性。
这里说一下我刚开始对工厂方法模式的简单理解：我刚开始接触到工厂方法模式的时候，以为很是很是麻烦，看上去工厂方法模式不就是在建立一个产品的实例么？我直接在客户端中进行初始化不就完事了么？用得着又是建立工厂又是建立产品的，好麻烦…其实若是你没有使用工厂方法模式：打个比方，你在 A 界面经过 new 的方式建立了一个我们上面代码中的 ConcreteProductA 的实例，这样看上去是比使用工厂方法模式要简单的多，可是，若是你在界面B、C、D、E等等界面中都是用到了 ConcreteProductA 这个对象呢？是，你可能会说，那也好办啊，直接建立不就好了。可是你有没有考虑过这么一种状况，若是说如今的 ConcreteProductA 的构造逻辑改变了，那你是否是须要在全部采用 new ConcreteProductA 的地方都要动代码，而使用 工厂方法模式就不会，应为 产品类的建立是在工厂中进行建立的，我只须要改一下工厂方法的逻辑便可；这是一方面，其实还有一个好处：就拿我们上面的例子来讲吧，如今有 A、B两个产品，若是没有采用工厂方法模式，那么咱们须要手动建立产品A和产品B的实例，若是说后面我不想使用产品A和产品B了，我这边要出一个新产品C，那么你经过 new 建立产品Ａ、B的地方是否是仍是要改？而工厂方法模式就不用，我只须要在工厂方法中将产品 C 返回便可。这就是工厂方法的最大优势。
工厂方法模式的实战
这里以一个生活中的小例子来讲明。好比说你是一家汽车生产厂的厂长，对你来讲，组装汽车没什么好神秘的，无非就是将一些进口的核心部件，好比发动机和一些国内的零部件组装起来，你的汽车厂主要就是组装某款 SUV 车型，好比 Q三、Q五、Q7，对于这类车型来讲，内部结构差别并非很大，所以，对你来讲，一条生产线足以应付 3 种车型，对于这类生产线能够提供这么一个抽象类定义：
public class AudiFactory {
public static T createAudiCar(Class clazz) {
AudiCar audiCar = null;
try {
audiCar = (AudiCar) Class.forName(clazz.getName()).newInstance();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
return (T) audiCar;
}
}
对于这 3 种车型，除了一些车都有的基本共性外，还提供了自动巡航功能，使用一个抽象基类来声明：
public abstract class AudiCar {
/**
* 汽车的抽象产品类
* 定义汽车的一个行为方法，车能够启动开走
*/
public abstract void drive();
/**
* 汽车的抽象产品类
* 定义汽车的一个行为方法，车能够自动巡航
*/
public abstract void selfNavigation();
}
接下来就是生产每一种具体的车型了：
public class AudiQ3 extends AudiCar {
@Override
public void drive() {
Log.d("AudiCar","Q3 启动啦！");
}
@Override
public void selfNavigation() {
Log.d("AudiCar","Q3 开启自适应巡航！");
}
}
public class AudiQ5 extends AudiCar {
@Override
public void drive() {
Log.d("AudiCar", "Q5 启动啦！");
}
@Override
public void selfNavigation() {
Log.d("AudiCar", "Q5 开启自适应巡航！");
}
}
public class AudiQ7 extends AudiCar {
@Override
public void drive() {
Log.d("AudiCar","Q7 启动啦！");
}
@Override
public void selfNavigation() {
Log.d("AudiCar","Q7 开启自适应巡航！");
}
}
最后咱们将个各种组装起来造成一条完整的流水线：
public class Test {
public static void main() {
AudiQ3 audiQ3 = AudiFactory.createAudiCar(AudiQ3.class);
audiQ3.drive();
audiQ3.selfNavigation();
AudiQ5 audiQ5 = AudiFactory.createAudiCar(AudiQ5.class);
audiQ5.drive();
audiQ5.selfNavigation();
AudiQ7 audiQ7 = AudiFactory.createAudiCar(AudiQ7.class);
audiQ7.drive();
audiQ7.selfNavigation();
}
}
总结
总的来讲，工厂方法模式是一个很好的设计模式，可是缺点也是难以免的，每次咱们为工厂方法模式添加新的产品时就要编写一个新的产品类，同时还要引入抽象层，这必然会致使类结构的复杂化，因此，在某些状况比较简单时，是否要使用工厂模式，须要设计者权衡利弊了。
扫一扫
449
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
