设计模式 工厂模式

概念

基本场景例子

我们写一个很简单的Demo后续使用模式去优化
定义接口car

package factory;

public interface Car {
    public void name();
}

定义两个实现类

package factory;

public class Tesla implements Car{
    @Override
    public void name() {
        System.out.println("特斯拉");
    }
}

package factory;

public class Wuling implements Car{
    @Override
    public void name() {
        System.out.println("五菱");
    }
}

定义一个消费者模拟看车

public class Consumer {
    public static void main(String[] args) {
        Car car1=new Tesla();
        Car car2=new Wuling();
        car1.name();
        car2.name();
    }
}

上面就是最基本的写法 我们尝试使用工厂模式优化这个场景

工程模式简单例子

写一个最简单的工厂类 这样外部调用时只需要给出车的名字即可创建对象 内部细节都被隐藏了

package factory;

public class CarFactory {
    public static Car getCar(String name){
        if("".equals(name)){
            return null;
        }
        else if("五菱".equals(name)){
            return new Wuling();
        }
        else if("特斯拉".equals(name)){
            return new Tesla();
        }
        else{
            return null;
        }
    }
}

当然这种最简单的写法肯定也是有缺点的 比如后续新加了一种车 那么工厂类就需要在同一个代码块加判断 违背了开闭原则
上面这种写法即静态工程模式 优点是实现简单 缺点是违背开闭原则

工厂方法模式解决开闭原则

很喜欢网友说的一句话 没有什么问题是加一层不可以解决的
我们额外定义一个CarFactory接口

public interface CarFactory {
    Car getCar();
}

同时一种车我们就写一个定义的工厂类
比如特斯拉:

package methodfactory;

public class TeslaFactory implements CarFactory {
    @Override
    public Car getCar() {
        return new Tesla();
    }
}

我们想获得车时就可以通过对应的工厂类获得:
new TeslaFactory().getCar().name();
这样写后我们要新加车时 就不会改动原来的代码
写好对应的工厂类即可
这种写法即是工厂方法模式 但是缺点就是代码量关于繁重
当然由于车的类创建过于简单 使得这么写看起来有点蠢
但是在大型项目开发中或多或少会有一些类创建十分复杂，通过工厂类封装了它们的创建细节，而创建工厂类就十分简单。
这时使不使用工厂模式就是天差地别