哈喽，大家好，我是一条~
国庆正是弯道超车的时候，向大家推荐一本个人觉得写的非常好的书——《redis深度历险 核心原理与应用实践》。
我们接着聊设计模式，新同学可以先看一下《23种设计模式的一句话通俗解读》全面的了解一下设计模式，形成一个整体的框架，再逐个击破。
今天我们一块看一下简单工厂模式，其实他不属于23种设计模式，但为了更好的理解后面的工厂方法和抽象工厂，我们还是需要先了解一下。
定义
官方定义
定义一个工厂类，他可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。
通俗解读
我们不必关心对象的创建细节，只需要根据不同参数获取不同产品即可。
难点：写好我们的工厂。
结构图
代码演示
本文源码：点击阅读原文 提取码: qr5h
目录结构
建议跟着一条学设计模式的小伙伴都建一个maven工程，并安装lombok依赖和插件。
并建立如下包目录，便于归纳整理。
pom如下
| <dependency> | |
| <groupId>org.projectlombok</groupId> | |
| <artifactId>lombok</artifactId> | |
| <version>1.16.10</version> | |
| </dependency> | |
开发场景
汽车制造工厂，既可以生产跑车，也可以生产SUV，未来还会生产新能源汽车。
代码实现
1.创建抽象产品Car
| public abstract class Car { | |
| public String color; | |
| abstract void run(); | |
| } |
2.创建具体产品
SuvCar
| public class SuvCar extends Car{ | |
| public SuvCar(){ | |
| this.color="green"; | |
| } | |
| @Override | |
| public void run() { | |
| System.out.println("SuvCar running---------"); | |
| } | |
| } |
SportsCar
| public class SportsCar extends Car{ | |
| public SportsCar(){ | |
| this.color="red"; | |
| } | |
| @Override | |
| public void run() { | |
| System.out.println("SportsCar running-------"); | |
| } | |
| } |
3.创建静态工厂
在简单工厂模式中用于被创建实例的方法通常为静态方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)。
| /** | |
| * 简单/静态工厂，少数产品 | |
| */ | |
| public class CarFactory { | |
| public static Car getCar(String type){ | |
| if (type.equals("sport")){ | |
| return new SportsCar(); | |
| }else if (type.equals("suv")){ | |
| return new SuvCar(); | |
| }else { | |
| return null; | |
| } | |
| } | |
| } |
4.编写测试类
| public class MainTest { | |
| public static void main(String[] args) { | |
| SportsCar sport = (SportsCar) CarFactory.getCar("sport"); | |
| sport.run(); | |
| System.out.println(sport.color); | |
| } | |
| } |
5.输出结果
接口和抽象类
补充一个知识： 接口和抽象类有什么区别？ 什么时候用接口，什么时候用抽象类？
接口和抽象类有什么区别？
- 接口是针对方法的整合，抽象类是针对子类的整合。
- 人有男人，女人，人是抽象类。人可以吃东西，狗也可以吃东西，吃东西这个动作是接口。
- 接口可以多继承，抽象类不行。
- 接口中基本数据类型为
static, 而抽象类不是。 - 抽象类有构造器，方法可以实现，除了不能被实例化，和普通类没有区别，接口不是。
什么时候用接口，什么时候用抽象类？
- 当你关注一个事物的本质的时候，用抽象类；当你关注一个操作的时候，用接口。
- 再简单点说，有属性定义的时候，用抽象类，只有方法的时候，用接口。
应用场景
- 工厂类负责创建对的对象比较少，因为不会造成工厂方法中的业务逻辑过于复杂
- 客户端只知道传入工厂类的参数，对如何创建对象不关心
- 由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。
总结
优点
- 通过工厂类，无需关注生产的细节，只需要传递对应参数即可。
- 可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。
缺点
- 违背开闭原则，扩展不易。
- 工厂类职责过重，一旦异常，系统瘫痪。
- 无法动态的增加产品，扩展困难。
问题：在不修改的工厂的前提下，怎么生产新能源汽车？下一节的工厂方法模式给大家讲解。