为什么需要创建型模式以及简单工厂模式（二）
创建型模式不同于其他模式，因为程序语言本身是支持创建对象实例的比如使用new关键字，比如通过反射创建，通过clone()方法创建对象
也可以在构造方法中对创建逻辑进行干预
那么，为什么还需要创建型模式？
### 创建型模式
#### 创建型模式概念特点
先看下前文说过的创建型模式概念
> 创建型模式是用来创建对象的模式，抽象了实例化的过程，封装了创建逻辑
> 1. 将系统所使用的具体类的信息封装起来
> 2. 隐藏了类的实例是如何被创建和组织的
**实例的创建与使用分离**
创建型模式的最基本功能就是将对象的创建和使用进行了分离
客户端程序不在关注对象的创建，通过创建型模式进行对象的获取
对象的创建和使用分离就能保证，对象的创建过程全部都被封装在创建型模式之中了
不再会散乱的存在于使用的类中，更加便于维护，也符合依赖倒置原则
**隐藏细节类型**
一旦使用创建型模式，就对客户端程序隐藏了对象创建的细节
甚至可以隐藏对象的具体类型，客户端程序可以仅仅面向抽象编程即可
不需要关注实际使用对象的具体类型，降低了耦合度
**逻辑清晰 个性化**
构造方法虽然可以封装创建初始化逻辑
但是，构造方法全都是一样的名字，使用创建型模式---比如工厂模式的话，你哪怕什么都不做
只是给多种用途的构造方法设置更加有自解释含义清晰的名字，都会增加可读性
另外
比如创建型的单例模式，仅仅返回一个对象的实例，如果将这种逻辑植入到构造方法中
将会显得不伦不类，因为new关键字构造方法就是单纯的创建对象
不应该将过多的业务逻辑植入其中，它仅适合用于一些初始化操作
使用单独的创建型模式，逻辑更加清晰
#### 场景
当你需要对客户端程序隐藏实际的对象类型时
当你想要隐藏实例对象的业务创建逻辑时
当你想要把对象的使用与创建进行分离时
等等想要更加个性化定制对象的创建过程的时候
都可以考虑使用创建型模式
### 简单工厂模式
工厂模式是简单常用的一种创建型模式
#### 概念
工厂模式是最基本的创建型模式，他有三种形式，简单工厂，工厂方法，抽象工厂
其中最基本的是简单工厂形式，简单工厂形式简单到很多时候不被称为一种模式，更像是一种经验习惯
简单工厂模式借助于工厂类的静态方法，根据参数的不同情况创建不同的对象
简言之就是：有一个类，他有一个静态方法， 这个静态方法根据条件判断需要创建的对象的类型
`作者:程序员潇然 疯狂的字节X https://crazybytex.com/`
#### 示例代码
考虑下面的这种场景
有水果类（抽象类、接口）Fruit用于描述水果
另有具体的水果（实现类）苹果Apple 橘子Orange
有一个简单的水果店SimpleFruitFactory 能够销售提供所有的水果
!(data/attachment/forum/202206/25/154159qcz4eeufcnc5efc5.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
ps：包名不应该有大写，应该尽可能地使用一个单词，实在无法避免也不要驼峰命名，全部小写
```java
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public interface Fruit {
String description();
}
```
```java
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Apple implements Fruit {
@Override
public String description() {
return "apple";
}
}
```
```java
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Orange implements Fruit {
@Override
public String description() {
return "Orange";
}
}
```
```java
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public enum FruitType {
APPLE,
ORANGE
}
```
```java
package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class SimpleFruitFactory {
public static Fruit create(FruitType fruitType){
if(fruitType.equals(FruitType.APPLE)){
return new Apple();
}else if(fruitType.equals(FruitType.ORANGE)){
return new Orange();
}
return null;
}
}
```
!(data/attachment/forum/202206/25/154542aaarjgrr8mgxn1nj.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
#### 结构
通过示例可以看得出来，简单工厂模式的确很简单
关键点就是这个静态create方法，内部使用if else结构或者switch结构
由于通常都是静态方法，所以又叫做静态工厂方法模式
模式如下图所示
!(data/attachment/forum/202206/25/154614o4eijs0jnxrjjucs.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
工厂类根据传入的参数决定创建哪一种类型的具体产品
**工厂类Factory**
一般就是具体的Java实现类，在客户端程序的请求下直接创建具体的产品，提供静态工厂方法
**抽象产品 Product**
工厂所创建对象的父类或者公共接口，一般是接口或者抽象类
**具体产品 ConcreteProduct**
创建的具体的实例对象
#### 特点
简单工厂模式特点：
**静态方法、根据参数确定待创建对象的类型**
当然，也可以不在一个方法中处理，也可以创建多个方法来创建不同的具体产品对象
而且，如果产品只有一种的话，也可以省略抽象的产品Product角色
!(data/attachment/forum/202206/25/154847ui6enp1yqwpq4y28.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "image.png")
简单工厂模式处于产品实例化的核心位置
他知道每个产品，也就是内部直接清楚创建的对象类型
他决定哪一个产品类应该被实例化
允许客户端程序与具体产品的创建过程独立，在系统引入新产品时，不需要修改客户端代码
所以说站在客户端程序的视角看待的话， 算是符合开闭原则
对于简单的场景，简单工厂模式是一个不错的选择，既能够获得工厂型模式的优点
又足够的简便清晰
**简单工厂模式根本特点就是一个工厂类包打天下，创建所有的产品**
#### 简单工厂模式缺点
既然叫做简单工厂模式，他的优点之一自然是简单
所有的创建逻辑都封装在了一个工厂类中，以不变应万变，所有产品的创建都尽在其中
但是**面对复杂的产品体系结构，优点就变成了缺点 ，可能就会过于臃肿复杂不易维护复用**
比如，如果新增加了子类，怎么办？
显然需要修改工厂的静态方法
想要扩展功能必须修改工厂类的代码，也就是**站在工厂类的角度，不符合开闭原则**
而且，面对复杂的产品体系结构，这个工厂类提供所有的创建逻辑
成了一个功能大而全的类，显然这**违背了单一职责原则**
也会更容易出现问题
!(data/attachment/forum/202206/16/141330jha7st9soow8772i.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/300 "common_log.png")
`转载务必注明出处：程序员潇然，疯狂的字节X，https://www.crazybytex.com/thread-5-1-1.html `
页:
[1]