1.1简单工厂模式
1.1.1看一个具体的需求:看一个披萨的项目:要便于披萨种类的扩展,要便于维护
- 披萨的种类很多(比如 GreekPizz、CheesePizz 等)
- 披萨的制作有 prepare,bake, cut, box
- 完成披萨店订购功能。
1.1.2使用传统的方式来完成
- 思路分析(类图)
package pattern.factory;
public class OrderPizza {
private SimpleFactory factory;
public OrderPizza(SimpleFactory factory) {
this.factory = factory;
}
public OrderPizza(String Type) {
Pizza pizza = null;
if (Type.equals("greek")) {
pizza = new GreekPizza();
pizza.setName(" 希腊披萨 ");
} else if (Type.equals("cheese")) {
pizza = new CheesePizza();
pizza.setName(" 奶酪披萨 ");
} else if (Type.equals("pepper")) {
pizza = new PepperPizza();
pizza.setName("胡椒披萨");
}
//输出 pizza 制作过程
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
}
private String getType() {
return null;
}
}
public class PepperPizza extends Pizza {}
public class CheesePizza extends Pizza {
}
public class GreekPizza extends Pizza {
}
public class Pizza {
private String name;
public void setName(String s) {
}
public void prepare() {
}
public void bake() {
}
public void cut() {
}
public void box() {
}
}
1.1.3传统的方式的优缺点
- 优点是比较好理解,简单易操作。
- 缺点是违反了设计模式的 ocp 原则,即对扩展开放,对修改关闭。即当我们给类增加新功能的时候,尽量不修改代码,或者尽可能少修改代码.
- 比如我们这时要新增加一个 Pizza 的种类(Pepper 披萨),我们需要做如下修改. 如果我们增加一个 Pizza 类,只要是订购 Pizza 的代码都需要修改.
结论
- 我们要去找到变化的地方进行抽取,在改动的时候只需要改动抽取的地方就可以,如下图是变化的地方
- 如果增加一个pizza种类就要多加一个类型,那我们不妨抽取出来,将这些if,抽象成只是一个制作pizza的步骤,比如createPizza(),而如何制作pizza的,则是我们抽取的部分。
1.1.4改进的思路分析
- 分析:修改代码可以接受,但是如果我们在其它的地方也有创建 Pizza 的代码,就意味着,也需要修改,而创建 Pizza
的代码,往往有多处。 - 思路:把创建 Pizza 对象封装到一个类中,这样我们有新的 Pizza 种类时,只需要修改该类就可,其它有创建到 Pizza
对象的代码就不需要修改了.-> 简单工厂模式
1.2使用简单工厂模式
- 简单工厂模式的设计方案: 定义一个可以实例化 Pizaa 对象的类,封装创建对象的代码。
public class SimpleFactory {
//更加 orderType 返回对应的 Pizza 对象
public Pizza createPizza(String orderType) {
Pizza pizza = null;
System.out.println("使用简单工厂模式");
if (orderType.equals("greek")) {
pizza = new GreekPizza();
pizza.setName(" 希腊披萨 ");
} else if (orderType.equals("cheese")) {
pizza = new CheesePizza();
pizza.setName(" 奶酪披萨 ");
} else if (orderType.equals("pepper")) {
pizza = new PepperPizza();
pizza.setName("胡椒披萨");
}
return pizza;
}
}
1.3工厂方法模式
1.3.1看一个新的需求
- 披萨项目新的需求:客户在点披萨时,可以点不同口味的披萨,比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza。
-
思路 1
- 使用简单工厂模式,创建不同的简单工厂类,比如 NYPizzaFactory、ChicogoPizzaFactory 等等.从当前这个案例来说,也是可以的,但是考虑到项目的规模,以及软件的可维护性、可扩展性并不是特别好
- 使用简单工厂模式,创建不同的简单工厂类,比如 NYPizzaFactory、ChicogoPizzaFactory 等等.从当前这个案例来说,也是可以的,但是考虑到项目的规模,以及软件的可维护性、可扩展性并不是特别好
-
思路 2
使用工厂方法模式
1.3.2工厂方法模式介绍- 工厂方法模式设计方案:将披萨项目的实例化功能抽象成抽象方法,在不同的口味点餐子类中具体实现。
- 工厂方法模式:定义了一个创建对象的抽象方法,由子类决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。
1.3.3工厂方法模式应用案例 - 披萨项目新的需求:客户在点披萨时,可以点不同口味的披萨,比如 北京的奶酪 pizza、北京的胡椒 pizza 或者是伦敦的奶酪 pizza、伦敦的胡椒 pizza
- UML图解方案
-
//OrderPizza.java 类
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import com.atguigu.factory.factorymethod.pizzastore.pizza.Pizza;
public abstract class OrderPizza {
//定义一个抽象方法,createPizza , 让各个工厂子类自己实现
abstract Pizza createPizza(String orderType);
// 构造器
public OrderPizza(){
Pizza pizza = null;
String orderType; // 订购披萨的类型
orderType = getType();
pizza = createPizza(orderType); //抽象方法,由工厂子类完成
//输出 pizza 制作过程
pizza.prepare(); pizza.bake();
pizza.cut();
pizza.box();
}
// 写一个方法,可以获取客户希望订购的披萨种类
private String getType(){
try{
BufferedReader strin = new BufferedReader(new InputStreamReader(System.in));
System.out.println("input pizza 种类:");
String str = strin.readLine();
return str;
}catch(IOException e){
e.printStackTrace(); return "";
}
}
}
public class BJOrderPizza extends OrderPizza {
@Override
Pizza createPizza(String orderType) {
Pizza pizza = null;
if(orderType.equals("cheese")){
pizza = new BJCheesePizza();
}else if(orderType.equals("pepper")){
pizza = new BJPepperPizza();
}
}
}
public class LDOrderPizza extends OrderPizza {
@Override
Pizza createPizza(String orderType) {
Pizza pizza = null;
if(orderType.equals("cheese")){
pizza = new LDCheesePizza();
} else if(orderType.equals("pepper")){
pizza = new LDPepperPizza();
}
}
}
1.4抽象工厂模式
1.4.1基本介绍
- 抽象工厂模式:定义了一个 interface 用于创建相关或有依赖关系的对象簇,而无需指明具体的类
- 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。
- 从设计层面看,抽象工厂模式就是对简单工厂模式的改进(或者称为进一步的抽象)。
- 将工厂抽象成两层,AbsFactory(抽象工厂) 和 具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇,更利于代码的维护和扩展。
- 类图
1.4.2抽象工厂模式应用实例:使用抽象工厂模式来完成披萨项目.
//一个抽象工厂模式的抽象层(接口) public interface AbsFactory {
//让下面的工厂子类来 具体实现
public Pizza createPizza(String orderType);
}
//这是工厂子类
public class BJFactory implements AbsFactory{
@Override
public Pizza createPizza(String orderType) {
System.out.println("~使用的是抽象工厂模式~");
Pizza pizza = null;
if(orderType.equals("cheese")){
pizza = new BJCheesePizza();
}else if(orderType.equals("pepper")){
pizza = new BJPepperPizza();
}
return pizza;
}
}
public class LDFactory implements AbsFactory {
@Override
public Pizza createPizza(String orderType){
System.out.println("~使用的是抽象工厂模式~");
Pizza pizza = null;
if (orderType.equals("cheese")){
pizza = new LDCheesePizza();
}else if (orderType.equals("pepper")){
pizza = new LDPepperPizza();
}
return pizza;
}
}
//OrderPizza.java
public class OrderPizza {
AbsFactory factory;
// 构造器
public OrderPizza(AbsFactory factory){
setFactory(factory);
}
private void setFactory(AbsFactory factory){
Pizza pizza = null;
String orderType = ""; // 用户输入
this.factory = factory;
orderType = getType();
// factory 可能是北京的工厂子类,也可能是伦敦的工厂子类
pizza = factory.createPizza(orderType);
if (pizza != null){
// 订 购 ok
pizza.prepare();
pizza.bake();
pizza.cut();
pizza.box();
} else {
System.out.println("订购失败"); break;
}
}
// 写一个方法,可以获取客户希望订购的披萨种类
private String getType(){
try{
BufferedReader strin = new BufferedReader(new InputStreamReader(System.in));
System.out.println("input pizza 种类:");
String str = strin.readLine();
return str;
}catch(IOException e){
e.printStackTrace();
return "";
}
}
}
总结
简单工厂
那么再用另一个实例总结一下,根据简单工厂之前的那段代码,其实就是我们每个人会去写的最普通的代码,而到了简单工厂模式,就是有一大类的pizza,然后分好几种pizza,然后由一个工厂去制作,说一个案例就是我们要开一个饭馆,我们有面条
反例
public class negtive {
/*===============服务端======================*/
interface Food{
void eat();
}
static class Noodles implements Food{
@Override
public void eat() {
System.out.println("吃面条。。。。。");
}
}
/*=================客户端===================*/
public static void main(String[] args) {
Food food01 = new Noodles();
food01.eat();
}
}
UML类图
这时候,产品来改需求来了,“哥,你先把刀放下。咱们现在这 Noodles改名了,得改个特牛逼的名字Spaghetti,让用户记住咱们这是西餐意大利面。”
这时候,因为你原有设计是上面的反例,你得能从修改服务端的源代码开始,再修改客户端源代码。以后再有改名这类事,你还要把刀拿出来放桌上给产品看。
这种设计过于脆弱,因为这样服务端源代码和客户端源代码是耦合的,改变会牵一发而动全身。
改成如下就可
public class postive {
/*===============服务端======================*/
interface Food{
void eat();
}
static class Spaghetti implements Food {
@Override
public void eat() {
System.out.println("吃西餐面条。。。。。");
}
}
static class FoodFactory {
public Food getFood(int num){
Food food =null;
switch (num){
case 1 :
food = new Spaghetti();
}
return food;
}
}
/*=================客户端===================*/
public static void main(String[] args) {
FoodFactory foodFactory = new FoodFactory();
Food food01 = foodFactory.getFood(1);
food01.eat();
}
}
UML类图
通过这样一个正例,把创建对象的代码全交给服务端处理,将服务端代码和客户端代码进行了解耦。以后产品再找你聊天是不是可以暂时把刀收起来了?
这样做的好处,不只是服务端开发人员受益,当服务端代码修改时,客户端也不知道,也不需要知道。这样的设计模式并不是十全十美的,任何一种设计模式都不会是十全十美的。只是根据业务逻辑在各方面进行取舍。
## 简单工厂模式的缺点:
客户必须记住工厂中常量和具体产品的映射关系。一旦产品品种体量增大到一定程度,工厂类将变得非常臃肿。最致命的缺陷,增加产品时,就要修改工厂类。违反开闭原则。
工厂方法模式
- 简述:为了进行扩展,不违反开闭原则。这里是基于简单工厂模式进行改进。
- 正例
public class postive {
/*===============服务端======================*/
//-----------------------产品--------------------
interface Food{
void eat();
}
static class Spaghetti implements Food {
@Override
public void eat() {
System.out.println("吃西餐面条。。。。。");
}
}
//新增产品
static class Rice implements Food {
@Override
public void eat() {
System.out.println("吃米饭。。。。。");
}
}
//--------------------------工厂-----------------------
interface FoodFactory {
Food getFood();
}
static class SpaghettiFactory implements FoodFactory{
@Override
public Food getFood() {
return new Spaghetti();
}
}
//新增产品工厂
static class RiceFactory implements FoodFactory{
@Override
public Food getFood() {
return new Rice();
}
}
/*=================客户端===================*/
public static void main(String[] args) {
FoodFactory foodFactory = new SpaghettiFactory();
Food food01 = foodFactory.getFood();
food01.eat();
}
}
- 针对简单工厂违反开闭原则的这一缺陷,工厂方法模式进行优化。可以看到此时再去增加产品,不再需要修改工厂类,而是增加相应的产品类和工厂类即可。这是符合开闭原则的。
这里就会有聪明的小问号有很多朋友了:
-
如果源代码作者修改相关工厂类的类名,那这时候调用工厂类的客户端代码就需要修改了,这不如简单工厂呢?
- 首先这里要明确一个概念,工厂类在实际使用中,是相当于接口类的,接口类一般不允许进行修改(非必须),工厂类作者有责任,有义务保证工厂类的类名是稳定的,也就是说,工厂类是比产品类更加稳定的。
-
既然使我们后面自己扩展的Rice类,为什么不直接实例化它,直接使用。我们就是作者,为什么不能直接使用?
- 这里需要扩展一下,有时候一个产品类并不是孤立的,它和其他类一起组成一个服务框架。
-
那么如何扩展呢,如下:
/*===============服务端======================*/
//------------------------产品质检流程-----------------------、
static class QualityInspection {
public void checking(FoodFactory foodFactory){
System.out.println("我是人肉质检员。。。。。准备开吃 -_- ");
Food food = foodFactory.getFood();
food.eat();
}
}
/*=================客户端===================*/
public static void main(String[] args) {
FoodFactory foodFactory01 = new SpaghettiFactory();
FoodFactory foodFactory02 = new RiceFactory();
QualityInspection inspection = new QualityInspection();
inspection.checking(foodFactory02);
inspection.checking(foodFactory01);
总体来说就是增加一个制作东西的工厂,再增加要制作的东西的类,实现以及继承就能实现扩展
UML类图
这时候,如果Rice没有他的工厂类,甚至都没办法参加质检,那还怎么卖?
- 所以编写工厂类并不只是单纯为了实例化某些产品类,而是能让配套服务通过工厂接口,得以调用工厂创建产品实例。
有的小朋友大大的眼睛里还有疑惑:那为什么QualityInspection的checking方法不直接调用Food接口再进行产品的实例化呢?
- 这时候回到简单工厂模式,产品类不同于工厂类,它是善变的,它会随着需求的变化而变化,这时候,直接依赖产品类的各种方法,将需要被修改,违反开闭原则。这是死路,小朋友别杠了。哈哈哈。
当然,工厂方法模式也是有缺陷的:
- 当业务需要的类型变多,目前只有食物,当产生饮料,日用品等类别时,我们又要创建新的工厂来实现,造成代码重复臃肿。
抽象工厂模式
针对工厂方法模式的缺陷,抽象工厂模式将进行改进,一个工厂负责创建一个产品簇的对象。
关于产品簇:是指多个存在内在联系的或者存在逻辑关系的产品。如图所示
![在这里插入图片描述](https://i-blog.csdnimg.cn/blog_migrate/f44c4f052e2e8070e66063bc8961f0c0.png)
简述:在抽象工厂模式中,接口是负责创建一个相关对象的工厂,不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
抽象工厂模式(Abstract Factory Pattern)是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式,它提供了一种创建对象的最佳方式。
在这里换一个例子,那就是我们我们要生产6号螺母以及8号螺母,对应着6号螺丝以及8号螺丝,这就出现了两类产品,两类工厂。代码如下
public class postive {
/*===============服务端======================*/
//-----------------------产品--------------------
/*----------------螺丝---------------------*/
interface Screw{
void createScrew();
}
static class Screw_06 implements Screw {
@Override
public void createScrew() {
System.out.println("create Screw_06 666666。。。。。");
}
}
static class Screw_08 implements Screw {
@Override
public void createScrew() {
System.out.println("create Screw_08 8888888。。。。。");
}
}
/*----------------螺母---------------------*/
interface Nut{
void createNut();
}
static class Nut_06 implements Nut {
@Override
public void createNut() {
System.out.println("create Nut_06 666666。。。。。");
}
}
static class Nut_08 implements Nut {
@Override
public void createNut() {
System.out.println("create Nut_08 8888888。。。。。");
}
}
//--------------------------工厂-----------------------
interface ComponentsFactory {
Screw getScrew();
Nut getNut();
}
/*----------------6号工厂---------------------*/
static class Factory_666 implements ComponentsFactory {
@Override
public Screw getScrew() {
return new Screw_06();
}
@Override
public Nut getNut() {
return new Nut_06();
}
}
/*----------------8号工厂---------------------*/
static class Factory_888 implements ComponentsFactory {
@Override
public Screw getScrew() {
return new Screw_08();
}
@Override
public Nut getNut() {
return new Nut_08();
}
}
//------------------------产品质检流程-----------------------、
static class QualityInspection {
public void checking(ComponentsFactory Factory){
System.out.println("我是人肉质检员。。。。。等待产出零件 -_- ");
Screw screw = Factory.getScrew();
Nut nut = Factory.getNut();
screw.createScrew();
nut.createNut();
System.out.println("开始质检.......");
System.out.println(" ");
}
}
/*=================客户端===================*/
public static void main(String[] args) {
ComponentsFactory Factory01 = new Factory_666();
ComponentsFactory Factory02 = new Factory_888();
QualityInspection inspection = new QualityInspection();
inspection.checking(Factory01);
inspection.checking(Factory02);
}
}
UML类图
可以看到,如果在需要进行一种N号螺丝或者螺母的扩展,只需要增加一个实现N号螺丝或者螺母接口的产品类,利用一个新增N号工厂进行创建即可。
可以看到,抽象工厂仍然保持着简单工厂模式和工厂方法模式的优点:
- 服务端代码和客户端代码是低耦合的。(简单工厂模式)
- 所有这一切动作都是新增,不是修改,符合开闭原则。
还新增了一个特有的优点:
- 抽象工厂有效减少了工厂的数量,一个工厂就生产同一个产品簇的产品。
这下产品来改需求,是不是还可以笑嘻嘻跟他聊会天了?
再次强调,一个抽象工厂负责创建同一个产品簇的对象。而产品簇是指多个存在内在联系的或者存在逻辑关系的产品。也就是6号工厂只生产6号的零部件,不负责生产8号零部件。不能不同产品簇的产品混合到一个工厂中进行生产。
缺陷:当增加产品簇时(增加6 、 8号螺帽的生产),这时候就要修改以前工厂(6 、 8号工厂)的源代码了。
总结就是:
当产品簇比较固定时,考虑使用抽象工厂。
当产品簇经常变动时,不建议使用抽象工厂。
故而如下:
工厂方法模式:
一个抽象产品类,可以派生出多个具体产品类。
一个抽象工厂类,可以派生出多个具体工厂类。
每个具体工厂类只能创建一个具体产品类的实例。
抽象工厂模式:
多个抽象产品类,每个抽象产品类可以派生出多个具体产品类。
一个抽象工厂类,可以派生出多个具体工厂类。
每个具体工厂类可以创建多个具体产品类的实例。
区别:
工厂方法模式只有一个抽象产品类,而抽象工厂模式有多个。
工厂方法模式的具体工厂类只能创建一个具体产品类的实例,而抽象工厂模式可以创建多个。