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

 

创建型模式  

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

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

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

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

创建型概念特点

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

创建型模式是用来创建对象的模式，抽象了实例化的过程，封装了创建逻辑

1. 将系统所使用的具体类的信息封装起来

2. 隐藏了类的实例是如何被创建和组织的

 

实例的创建与使用分离

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

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

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

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

 

隐藏细节类型

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

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

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

 

逻辑清晰 个性化

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

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

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

另外

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

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

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

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

 

场景

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

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

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

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

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

 

简单工厂模式

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

概念

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

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

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

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

 

示例代码

考虑下面的这种场景

有水果类（抽象类、接口）Fruit用于描述水果

另有具体的水果（实现类）苹果Apple 橘子Orange

有一个简单的水果店SimpleFruitFactory 能够销售提供所有的水果

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

测试代码

结构

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

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

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

模式如下图所示

 

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

工厂类Factory

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

抽象产品 Product

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

具体产品 ConcreteProduct

创建的具体的实例对象

 

特点

简单工厂模式特点：

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

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

 

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

 

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

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

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

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

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

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

又足够的简便清晰

 

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

 

简单工厂模式缺点

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

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

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

 

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

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

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

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

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

也会更容易出现问题