为什么需要创建型模式以及简单工厂模式（三）

创建型模式

创建型模式不同于其他模式，因为程序语言本身是支持创建对象实例的 

比如使用new关键字，比如通过反射创建，通过clone()方法创建对象

也可以在构造方法中对创建逻辑进行干预

那么，为什么还需要创建型模式？  

创建型概念特点

先看下前文说过的创建型模式概念

实例的创建与使用分离

创建型模式的最基本功能就是将对象的创建和使用进行了分离

客户端程序不在关注对象的创建，通过创建型模式进行对象的获取

对象的创建和使用分离就能保证，对象的创建过程全部都被封装在创建型模式之中了

不再会散乱的存在于使用的类中，更加便于维护，也符合依赖倒置原则

隐藏细节类型

一旦使用创建型模式，就对客户端程序隐藏了对象创建的细节

甚至可以隐藏对象的具体类型，客户端程序可以仅仅面向抽象编程即可

不需要关注实际使用对象的具体类型，降低了耦合度

逻辑清晰 个性化

构造方法虽然可以封装创建初始化逻辑

但是，构造方法全都是一样的名字，使用创建型模式---比如工厂模式的话，你哪怕什么都不做

只是给多种用途的构造方法设置更加有自解释含义清晰的名字，都会增加可读性

另外

比如创建型的单例模式，仅仅返回一个对象的实例，如果将这种逻辑植入到构造方法中

将会显得不伦不类，因为new关键字构造方法就是单纯的创建对象

不应该将过多的业务逻辑植入其中，它仅适合用于一些初始化操作

使用单独的创建型模式，逻辑更加清晰

场景

当你需要对客户端程序隐藏实际的对象类型时

当你想要隐藏实例对象的业务创建逻辑时

当你想要把对象的使用与创建进行分离时

等等想要更加个性化定制对象的创建过程的时候

都可以考虑使用创建型模式   

简单工厂模式

而工厂模式是简单常用的一种创建型模式

概念

工厂模式是最基本的创建型模式，他有三种形式，简单工厂，工厂方法，抽象工厂

其中最基本的是简单工厂形式，简单工厂形式简单到很多时候不被称为一种模式，更像是一种经验习惯 

简单工厂模式借助于工厂类的静态方法，根据参数的不同情况创建不同的对象

简言之就是：有一个类，他有一个静态方法， 这个静态方法根据条件判断需要创建的对象的类型

示例代码

image_5be1399f_7e53

ps：包名不应该有大写，应该尽可能地使用一个单词，实在无法避免也不要驼峰命名，全部小写

package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public interface Fruit {
String description();
}

package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Apple implements Fruit {
@Override
public String description() {
return "apple";
}
}

package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public class Orange implements Fruit {
@Override
public String description() {
return "Orange";
}
}

package simpleFactory;
/**
* Created by noteless on 2018/10/9.
* Description:
*/
public enum FruitType {
APPLE,
ORANGE
}

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;
}
}

测试代码

image_5be1399f_4868

结构

通过示例可以看得出来，简单工厂模式的确很简单

关键点就是这个静态create方法，内部使用if else结构或者switch结构

由于通常都是静态方法，所以又叫做静态工厂方法模式

模式如下图所示

image_5be1399f_34dd

工厂类根据传入的参数决定创建哪一种类型的具体产品

工厂类Factory

一般就是具体的Java实现类，在客户端程序的请求下直接创建具体的产品，提供静态工厂方法

抽象产品 Product

工厂所创建对象的父类或者公共接口，一般是接口或者抽象类

具体产品 ConcreteProduct

创建的具体的实例对象

特点

简单工厂模式特点：

静态方法、根据参数确定待创建对象的类型

当然，也可以不在一个方法中处理，也可以创建多个方法来创建不同的具体产品对象

而且，如果产品只有一种的话，也可以省略抽象的产品Product角色

image_5be1399f_54d5

简单工厂模式处于产品实例化的核心位置

他知道每个产品，也就是内部直接清楚创建的对象类型

他决定哪一个产品类应该被实例化

允许客户端程序与具体产品的创建过程独立，在系统引入新产品时，不需要修改客户端代码

所以说站在客户端程序的视角看待的话， 算是符合开闭原则

对于简单的场景，简单工厂模式是一个不错的选择，既能够获得工厂型模式的优点

又足够的简便清晰

简单工厂模式根本特点就是一个工厂类包打天下，创建所有的产品

简单工厂模式缺点

既然叫做简单工厂模式，他的优点之一自然是简单

所有的创建逻辑都封装在了一个工厂类中，以不变应万变，所有产品的创建都尽在其中

但是面对复杂的产品体系结构，优点就变成了缺点 ，可能就会过于臃肿复杂不易维护复用

比如，如果新增加了子类，怎么办？

显然需要修改工厂的静态方法

想要扩展功能必须修改工厂类的代码，也就是站在工厂类的角度，不符合开闭原则

而且，面对复杂的产品体系结构，这个工厂类提供所有的创建逻辑

成了一个功能大而全的类，显然这违背了单一职责原则

也会更容易出现问题