首页 > 其他分享 >为什么需要创建型模式以及简单工厂模式(二)

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

时间:2022-12-29 15:02:40浏览次数:39  
标签:对象 创建 简单 模式 工厂 客户端程序

简单工厂模式又称为静态工厂模式是设计模式的基础模式,本文首先介绍了创建型设计模式的特点,使用场景,然后介绍了简单工厂模式的概念,特点,示例代码,以及简单工厂模式的缺点

 

创建型模式

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

比如使用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结构

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

模式如下图所示

 

​​为什么需要创建型模式以及简单工厂模式(二)_工厂类_02​​

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

工厂类Factory

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

抽象产品 Product

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

具体产品 ConcreteProduct

创建的具体的实例对象

 

特点

简单工厂模式特点:

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

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

 

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

​​为什么需要创建型模式以及简单工厂模式(二)_工厂类_03​​

 

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

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

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

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

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

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

又足够的简便清晰

 

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

 

简单工厂模式缺点

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

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

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

 

比如,如果新增加了子类,怎么办?

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

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

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

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

也会更容易出现问题

 



标签:对象,创建,简单,模式,工厂,客户端程序
From: https://blog.51cto.com/u_15628606/5977605

相关文章