工厂模式(简单工厂+工厂方法+抽象工厂)

时间:2022-10-01 23:27:50

简单工厂模式:

public interface Car(){
    public void run();
}
public class Audi implements Car(){
    @Override
    public void run(){
        System.out.println("奥迪在跑!");
    }
}
public class Benz implements Car{
    @Override
    public void run(){
        System.out.println("奔驰在跑!");
    }
}
public class CarFactory{
    public static Car createCar(String type){
    Car c=null;
    if("奥迪".equals(type)){
        c=new Audi();
        }else if("奔驰".equals(type)){
            c=new Benz();
        }
        return c;
    }
}
public class Client{
    public static void main(String []){
        Car c1 =CarFactory.createCar("奥迪");
        Car ce =CarFactory.createCar("奔驰");
        c1.run();
        c2.run();
    }
}

  工厂模式(简单工厂+工厂方法+抽象工厂)

 

 

常用的场景

例如部署多种数据库的情况,可能在不同的地方要使用不同的数据库,此时只需要在配置文件中设定数据库的类型,每次再根据类型生成实例,这样,不管下面的数据库类型怎么变化,在客户端看来都是只有一个AbstractProduct,使用的时候根本无需修改代码。提供的类型也可以用比较便于识别的字符串,这样不用记很长的类名,还可以保存为配置文件。

这样,每次只需要修改配置文件和添加新的产品子类即可。

所以简单工厂模式一般应用于多种同类型类的情况,将这些类隐藏起来,再提供统一的接口,便于维护和修改。

优点

1.隐藏了对象创建的细节,将产品的实例化推迟到子类中实现。

2.客户端基本不用关心使用的是哪个产品,只需要知道用哪个工厂就行了,提供的类型也可以用比较便于识别的字符串。

3.方便添加新的产品子类,每次只需要修改工厂类传递的类型值就行了。

4.遵循了依赖倒转原则。

缺点

1.要求产品子类的类型差不多,使用的方法名都相同,如果类比较多,而所有的类又必须要添加一种方法,则会是非常麻烦的事情。或者是一种类另一种类有几种方法不相同,客户端无法知道是哪一个产品子类,也就无法调用这几个不相同的方法。

2.每添加一个产品子类,都必须在工厂类中添加一个判断分支,这违背了开放-封闭原则。

 

一、给我一句话概括

简单工厂:工厂类中,根据条件决定一个接口由哪个具体产品类来实现。

工厂方法:创建多个工厂类。各个工厂类中,都对应一个获得接口A实例的方法。用户决定使用哪个工厂。

抽象工厂:对工厂方法进行扩展。各个工厂类中,再增加一个获得接口B实例的方法。

提一下,多个工厂类都继承自同一个接口。

二、这是什么鬼

1、工厂方法这样折腾,有意思吗,玩我呢?你不就是简单工厂披了个马甲?

2、抽象工厂,你和工厂方法有啥区别,你多个功能就敢自立门户了?

三、原来如此

工厂方法多加一层工厂封装类的意义在于:1、用户并不想关心产品接口是怎么实现的,如果这个实现过程和逻辑比较复杂呢?将这个过程封装到工厂类中,别的地方也可以重用;2、接口的具体怎么实现,全部交给另一个人去做(他写的产品类)。如果添加一个新产品,那么他再添加一个工厂类和产品类,用户使用这个工厂类即可。

工厂类可以继承于某个接口,或是抽象类,工厂类已经对产品类的实现就行了封装,用户用它结合配置参数和反射实现动态创建,是很合理的。相比简单工厂是不太合适的。

代码底层,当产品类创建分支是固定或是其他类似的地方很少时,用简单工厂很合适。因为一旦增加分支,改的地方很少。如果不是,建议用工厂方法。

抽象工厂和工厂方法没有本质区别,是对工厂方法的扩展。当产品类,涉及到多个产品簇时,需要对同类的产品抽象为一个接口。工厂类中,可以定义多个返回具体产品的方法,*组合。