(2)设计模式之--创建型模式---工厂方法模式Factory Method

时间:2022-10-02 14:14:41

本节讲解关于创建型模式工厂方法模式:个人认为设计模式在设计开发中是很重要的,故而把java 的23种设计模式进行总结回顾一下,再次学习学习,以此提升自己的技能。谢谢。、

创建型模式有以下六种:


简单工厂模式Simple Factory

工厂方法模式Factory

抽象工厂模式abstract Factory

原型模式prototype

单例模式Singleton

创建者模式Builder


简单来说,工厂方法模式相对于简单工厂模式来说,就是把一个单一的工厂类,分成了多个具体的小工厂,并抽象出一个工厂类,这个工厂类只负责定义创建的方式,创建具体内容由继承它的小工厂类来实现。

工厂方法(Factory Method)模式简介

工厂方法(Factory Method)模式的意义是定义一个创建产品对象的工厂接口,将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建,这样核心类成为一个抽象工厂角色,仅负责具体工厂子类必须实现的接口,这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。 工厂方法模式是简单工厂模式的衍生,解决了许多简单工厂模式的问题。首先完全实现‘开-闭 原则’,实现了可扩展。其次更复杂的层次结构,可以应用于产品结果复杂的场合。(2)设计模式之--创建型模式---工厂方法模式Factory Method

  工厂方法的结构

工厂方法模式的对简单工厂模式进行了抽象。有一个抽象的Factory类(可以是抽象类和接口),这个类将不再负责具体的产品生产,而是只制定一些规范,具体的生产工作由其子类去完成。在这个模式中,工厂类和产品类往往可以依次对应。即一个抽象工厂对应一个抽象产品,一个具体工厂对应一个具体产品,这个具体的工厂就负责生产对应的产品。 工厂方法模式(Factory Method pattern)是最典型的模板方法模式(Templete Method pattern)应用。




工厂方法模式角色与结构


  

抽象工厂(Creator)角色:是工厂方法模式的核心,与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。
具体工厂(Concrete Creator)角色:这是实现抽象工厂接口的具体工厂类,包含与应用程序密切相关的逻辑,并且受到应用程序调用以创建产品对象。在上图中有两个这样的角色:BulbCreator与TubeCreator。 抽象产品(Product)角色:工厂方法模式所创建的对象的超类型,也就是产品对象的共同父类或共同拥有的接口。在上图中,这个角色是Light。 具体产品(Concrete Product)角色:这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建,它们之间往往一一对应。

(2)设计模式之--创建型模式---工厂方法模式Factory Method


工厂方法模式的应用

工厂方法经常用在以下两种情况中: 第一种情况是对于某个产品,调用者清楚地知道应该使用哪个具体工厂服务,实例化该具体工厂,生产出具体的产品来。Java Collection中的iterator() 方法即属于这种情况。 第二种情况,只是需要一种产品,而不想知道也不需要知道究竟是哪个工厂为生产的,即最终选用哪个具体工厂的决定权在生产者一方,它们根据当前系统的情况来实例化一个具体的工厂返回给使用者,而这个决策过程这对于使用者来说是透明的。


下面对一个案例进行详解:
1.抽象动物类
package cn.victor.factorymethod;

public interface Animal {
public void eat();
}


2.具体动物类

package cn.victor.factorymethod;

public class Tiger implements Animal {

@Override
public void eat() {
// TODO Auto-generated method stub
System.out.println("老虎会吃");
}

public void run() {
System.out.println("老虎会跑");
}
}


package cn.victor.factorymethod;

public class Parrot implements Animal {

@Override
public void eat() {
// TODO Auto-generated method stub
System.out.println("鹦鹉会吃");
}
public void fly(){
System.out.println("鹦鹉会飞");
}
}


package cn.victor.factorymethod;

public class Dolphin implements Animal {

@Override
public void eat() {
// TODO Auto-generated method stub
System.out.println("海豚会chi");
}
public void swin(){
System.out.println("海豚会游泳");
}

}

3.抽象工厂类


package cn.victor.factorymethod;

public interface Factory {
public Animal createAnimal();
}


4.具体工厂类


package cn.victor.factorymethod;

public class TigerFactory implements Factory {

@Override
public Animal createAnimal() {
// TODO Auto-generated method stub
return new Tiger();
}

}

package cn.victor.factorymethod;

public class DolphinFactory implements Factory {

@Override
public Animal createAnimal() {
// TODO Auto-generated method stub
return new Dolphin();
}

}

package cn.victor.factorymethod;

public class ParrotFactory implements Factory {

@Override
public Animal createAnimal() {
// TODO Auto-generated method stub
return new Parrot();
}

}


5.客户端类

package cn.victor.factorymethod;

public class Client {

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
Factory factory=new TigerFactory();
Animal animal=factory.createAnimal();
animal.eat();

factory=new DolphinFactory();
Animal animal2=factory.createAnimal();
animal2.eat();

factory=new ParrotFactory();
Animal animal3=factory.createAnimal();
animal3.eat();
}

}

以上内容就是一个具体的工厂方法模式完整的案例讲解。


优缺点:

优点:

在工厂方法模式中,客户端不在负责对象的创建,而是把这个责任交给了具体的工厂类,客户端只负责对象的调用,从而明确了各个类的职责。


如果有新产品加进来,只需要新增加一个具体的创建 产品工厂类和具体的产品类就可以了。,不会影响到原来的已有的其他代码,代码量也不会变大,,后期维护更容易,增强了系统的可扩展性。


首先,良好的封装性,代码结构清晰。一个对象创建是有条件约束的,如一个调用者需要一个具体的产品对象,只要知道这个产品的类名(或约束字符串)就可以了,不用知道创建对象的艰辛过程,减少模块间的耦合。 


      其次,工厂方法模式的扩展性非常优秀。在增加产品类的情况下,只要适当地修改具体的工厂类或扩展一个工厂类,就可以完成“拥抱变化”。例如在我们的例子中,需要增加一个棕色人种,则只需要增加一个BrownHuman类,工厂类不用任何修改就可完成系统扩展。 


      再次,屏蔽产品类。这一特点非常重要,产品类的实现如何变化,调用者都不需要关心,它只需要关心产品的接口,只要接口保持不表,系统中的上层模块就不要发生变化,因为产品类的实例化工作是由工厂类负责,一个产品对象具体由哪一个产品生成是由工厂类决定的。在数据库开发中,大家应该能够深刻体会到工厂方法模式的好处:如果使用JDBC连接数据库,数据库从MySql切换到Oracle,需要改动地方就是切换一下驱动名称(前提条件是SQL语句是标准语句),其他的都不需要修改,这是工厂方法模式灵活性的一个直接案例。 


      最后,工厂方法模式是典型的解耦框架。高层模块值需要知道产品的抽象类,其他的实现类都不用关心,符合迪米特原则,我不需要的就不要去交流;也符合依赖倒转原则,只依赖产品类的抽象;当然也符合里氏替换原则,使用产品子类替换产品父类,没问题! 


缺点:

使用该模式需要额外的编写代码,增加了工作量





参考文章:

参考文章