探索设计模式的魅力:简单工厂模式
设计模式专栏:http://t.csdnimg.cn/U54zu 简单工厂模式(Simple Factory Pattern)是一种创建型设计模式,其主要目的是用于创建对象的实例。这种模式通过封装创建对象的代码来降低客户代码与具体类之间的耦合度。简单工厂不是GoF(四人帮)设计模式之一,但它是一个常用
设计模式专栏:http://t.csdnimg.cn/U54zu
简单工厂模式(Simple Factory Pattern)是一种创建型设计模式,其主要目的是用于创建对象的实例。这种模式通过封装创建对象的代码来降低客户代码与具体类之间的耦合度。简单工厂不是GoF(四人帮)设计模式之一,但它是一个常用的编程惯用法。
在简单工厂模式中,创建对象的责任通常由一个单一的工厂类承担,这个工厂类有一个用来根据输入参数创建并返回不同类型对象实例的方法。这种模式通常用于管理和创建那些具有共同接口或父类的一组类的实例。
一、业务案例
请用程序实现输入两个整数和运算符,然后输出结果。
二、一坨坨代码实现
两三下就搞定,代码如下:
import java.util.Scanner;
public class Tester {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
int a = scanner.nextInt();
int b = scanner.nextInt();
String c = scanner.nextLine().trim();
scanner.close();
switch (c) {
case "+": {
System.out.println(a + b);
return;
}
case "-": {
System.out.println(a - b);
return;
}
case "*": {
System.out.println(a * b);
return;
}
case "/": {
if (b == 0) {
return;
}
System.out.println(a / b);
return;
}
default: return;
}
}
}
正常运行看结果看似没有什么毛病,但阅读一下代码就实在不康入目
- 看不懂变量abc代码什么意思。
- 好多判断。
- 如果第一次和第二次输入符号会出错 等等。
把以上问题全部解决就行了么?当然不行,Java是面向对象编程。
三、简单工厂模式
3.1 面向对象编程
面向对象编程是一种基于对象和类的编程方法,它将数据和操作数据的方法封装在一起,以创建对象。在Java中,你可以通过类、对象、封装、继承和多态来构建复杂的软件系统。这些概念使得代码更具可维护性、可重用性和扩展性,是Java编程语言的重要特征之一。
3.1.2 接口
Java中的接口是一种抽象数据类型,它定义了一组方法的规范,但没有提供方法的具体实现。接口可以被类实现,一个类可以实现一个或多个接口。
在Java中,通过使用
interface
关键字来声明接口。接口的方法默认是public
和abstract
的,也就是说,接口中的方法必须是公共的和抽象的,不需要显式地声明这两个修饰符。
接口可以包含以下类型的成员:
- 抽象方法:接口中的方法没有方法体,只有方法签名。
- 默认方法:在Java 8中引入的,默认方法在接口中有一个具体的实现。实现类可以直接继承默认方法,也可以选择覆盖它们。
- 静态方法:在Java 8中引入的,接口中的静态方法可以通过接口名称直接调用,无需通过实现类。
- 常量:接口中可以定义常量,它们默认是
public
、static
和final
的。
接口的主要作用是实现多继承或多重实现。通过实现接口,一个类可以同时拥有多个接口定义的行为,并且可以在不同的类之间共享和重用代码。一个类可以实现多个接口,但只能继承一个类。
3.1.2 面向接口编程
Java面向接口编程是一种编程思想和重要的原则,它强调程序设计应该以接口为基础进行。这种编程方式的关键思想是将接口作为代码组织和交互的核心,而不是将具体的实现细节暴露给调用者。
在面向接口编程中,接口是一种契约,它定义了一组方法的规范。类可以实现接口,以表明它们能够提供接口中定义的行为。通过使用接口,可以减少代码之间的耦合性,并提高代码的可读性、可维护性和可扩展性。
面向接口编程的优点包括:
- 扩展性:通过定义接口,可以方便地添加新的实现类,从而提供更多的功能扩展点。
- 可替换性:由于面向接口编程的关注点是接口而不是具体实现,所以可以方便地替换实现类,以满足不同的需求和场景。
- 可测试性:接口的抽象性使得可以更容易地对代码的不同部分进行单元测试和模拟。
- 代码复用性:通过多个类实现同一个接口,可以实现代码逻辑的复用。
- 降低耦合性:通过依赖于接口而不是具体的实现类,可以降低代码之间的耦合性,提高系统的灵活性和可维护性。
在实践中,面向接口编程可以结合工厂模式来进一步提高代码的可扩展性和灵活性。在Java 程序设计里面,非常讲究层的划分和模块的划分,每层之间只通过接口来通信,而不需要知道具体的实现。
总的来说,接口提供了一种规范和契约的机制,用于定义类应该实现的方法,以及类们之间的协议。
3.2 不用设计模式解决
结构图如下
代码实现如下:
(接口)
/**
* 运算接口 <br/>
*
* @author danci_
* @date 2024/1/13 11:13:00
*/
public interface CalApi {
/**
* 根据传入的两个数字和运算符获得运算结果
*
* @param number1 数字1
* @param number2 数字2
* @param operator 运算符
* @return
*/
int cal(int number1, int number2, String operator);
}
(实现类)
/**
* 运算实现类 <br/>
*
* @author danci_
* @date 2024/1/13 11:14:46
*/
public class CalApiImpl implements CalApi {
@Override
public int cal(int number1, int number2, String operator) {
switch (operator) {
case "+": {
return number1 + number2;
}
case "-": {
return number1 - number2;
}
case "*": {
return number1 * number2;
}
case "/": {
if (number2 == 0) {
return 0;
}
return number1 / number2;
}
default: return 0;
} }
}
(客户端实现)
public class Client {
public static void main(String[] args) {
CalApi calApi = new CalApiImpl();
calApi.cal(1, 2, "+");
}
}
问题
客户的这行代码 CalApi calApi = new CalApiImpl(),客户端不仅知道了接口还知道了接口具体的实现,违背面向接口编程的思想。
使用工厂模式来解决问题。
3.3 用简单工厂模式解决
定义⼀个创建对象的接口,让其子类⾃己决定实例化哪⼀个工厂类,⼯厂模式使其创建过程延迟到⼦子类进⾏。
解决思路
客户端不应该知道具体的实现类,只知道接口又不应该知道具体的实现来满足业务,该怎么办?而创建接口又是需要知道实现类的。
创建一个工厂类,由工厂类来实例化接口,对外提供能获取接口的实例对象,然后就可以操作接口的方法了。
客户端通过工厂类来获取接口对象来调接口对应的方法。如此,实现了客户端不需要知道具体的接口实现了。
3.3.1 工厂模式结构及说明
- Api:定义客户所需要的功能接口。
-
Impl:具体实现Api 的实现类,可能会有多个。
-
Fact ory: 工厂,选择合适的实现 类来创建Api 接又对象。
-
Client:客户端,通过Factory 来获取Api接又对象,然后面向Api接又编程。
代码实现如下:
定义接口,代码如下:
public interface CalApi {
/**
* 根据传入的两个数字进行运算
*
* @param number1 数字1
* @param number2 数字2
* @return
*/
int cal(int number1, int number2);
}
运算实现类,代码如下:
public class AdditionCalApi implements CalApi {
/**
* 获取数字number1 + 数字number2的结果
*
* @param number1 数字1
* @param number2 数字2
* @return int 加法运算结果
*/
@Override
public int cal(int number1, int number2) {
return number1 + number2;
}
}
public class SubtractionCalApi implements CalApi {
/**
* 获取数字number1 - 数字number2的结果
*
* @param number1 数字1
* @param number2 数字2
* @return
*/
@Override
public int cal(int number1, int number2) {
return number1 - number2;
}
}
创建工厂类,代码如下:
public class Factory {
public static CalApi getCalApi(String operator) {
switch (operator) {
case "+": {
return new AdditionCalApi();
}
case "-": {
return new SubtractionCalApi();
}
default: return null;
}
}
}
客户端如何使用工厂?客户端就不用再自己去创建接口的对象了,应该使用工厂来获取 。 经过改造,客户端代码如下:
public class Client {
public static void main(String[] args) {
CalApi calApi1 = Factory.getCalApi("+");
int rs1 = calApi1.cal(12, 55);
System.out.println(rs1);
CalApi calApi2 = Factory.getCalApi("-");
int rs2 = calApi2.cal(12, 55);
System.out.println(rs2);
}
}
客户端通过简单工厂创建 了一个实现接口的对象,然后面向接口编程,从客户端来看,它根本不知道具体的实现是什么,也不知道是如何实现的,它只知道通过工厂获得了一个接口对象 , 然后通过这个接口来获取想要的功能。
3.3.2 模式分解
- 客户端与接口具体的实现类实现了完全的解藕。
- 工厂类跟接口和接口的实现在一起的,是一个封装体。(如下图)
图3 中的虚线框,就好比是一个组件的包装边界,表示接口、实现类和工厂类组合成了一 个组件。在这个封装体里面,只有接口和工厂是对外的,也就是让外部知道并使用的 ,所以故意漏了一些在虚线框外,而具体的实现类是不对外的,被完全包含在虚线框内。
对于客户端而言,只是知道了接口Api和简单工厂Factory,通过Factory 就可以获得Api 了,这样就达到了让Client在不知道具体实现类的情况下获取接口Api。 所以看似简单地将new Impl (这句话从客户端里面移动到了简单工厂里面,其实是有了质的变化的。
3.3.3 理解简单工厂模式
简单工厂模式(Simple Factory Pattern)属于创建型设计模式之一,其核心思想是通过一个专门的工厂类来负责创建其他类的实例,将实例的创建与使用解耦,减少客户端直接创建对象的责任。
简单工厂模式通常涉及以下三个角色:
-
工厂角色(Factory):这是简单工厂模式的核心,含有一个创建产品的方法,客户端调用这个方法来请求产品。根据传入的参数,工厂决定创建哪一种产品。
-
抽象产品角色(Product):这是工厂需要创建的所有对象的父类或接口,通常是一个抽象类或接口,定义了产品的公共接口。
-
具体产品角色(Concrete Product):工厂方法创建的具体实例,这些产品是继承自抽象产品或实现了产品接口的类。
简单工厂模式的核心思想可以概括为:
-
集中管理:将对象的创建集中到一个位置,便于管理和维护。
-
解耦:减少系统中的代码耦合,使用者不需要知道具体的产品类名,只需要知道工厂类和产品的抽象接口。
-
易于扩展:增加新的产品类时,只需在工厂类中新增相应的创建逻辑即可,对其他类的修改较小,遵循开闭原则(在扩展时,不需要修改现有代码,只需要增加新的代码)。
但是,简单工厂模式也有其局限性:
- 工厂类的职责相对比较重,如果产品种类非常多,工厂方法会变得非常复杂。
- 当增加新产品时,需要修改工厂类,这违反了开闭原则(对扩展开放,对修改封闭)。
3.4 简单工厂模式优缺点
优点:
- 帮助封装:简单工厂虽然很简单,但是非常友好帮我们实现了组件的封装,然后让组件外部能真正面向接口编程。
-
解耦:通过简单工厂,实现了客户端和具体实现类的解耦。如同上面的例子,客户端根本就不知道具体是由谁来实现,也不知道具体是如何实现的,客户端只是通过工厂获取它需要的接口对象。
缺点:
-
可能增加客户端的复杂度:如果通过客户端的参数来选择具体的实现类,那么就必须让客户端能理解各个参数所代表的具体功能和含义,这样会增加客户端使用的难度,也部分暴露了内部实现,这种情况可以选用可配置的方式来实现。
-
不方便扩展子工厂:私有化简单工厂的构造方法,使用静态方法来创建接口,也就不能通过写简单工厂类的子类来改变创建接口的方法的行为了。不过,通常情况下是不需要为简单工厂创 建子类的。
3.5 思考简单工厂模式
3.5.1 本质
筒单工厂的本质是:选择实现。
简单工厂的重点在选择,实现是已经做好了的。就算实现再简单,也要由具体的实现类来实现,而不是在简单工厂里面来实现。简单工厂的目的在于为客户端来选择相应的实现,从而使得客户端和实现之间解耦。这样一来,具体实现发生了变化,就不用变动客户端了,这个变化会被简单工厂吸收和屏蔽掉。
实现简单工厂的难点就在于 “如何选择” 实现,前面便子中传递参数的方法, 那都是静态的参数,还可以实现成为动态的参数。比如,在运行期间,由工厂去读取某个内存的值,或者是去读取数据库中的值,然后根据这个值来选择具体的实现等。
3.5.2 何时选用简单工厂模式
建议在以 下情况中选用简单工厂:
- 如果想要完全封装隔离具体实现,让外部只能通过接又来操作封装体,那么可 以选用简单工厂,让客户端通过工厂来获取相应的接又,而无须关心具体的实现。
-
如果想要把对外创建对象的职责集中管理和控制,可以选用简单工厂,一个简 单工厂可以创建很多的、不相关的对象,可以把对外创建对象的职责集中到一个简单 工厂来,从而实现集中管理和控制。
3.6 相关设计模式结合
简单工厂模式本身是一个非常基础的创建型模式,它是许多更复杂设计模式的起点。虽然它具有一定的局限性,但是在与其他设计模式结合使用时,它可以帮助更好地组织和管理代码。以下是几种与简单工厂模式相结合的设计模式,以及这种结合的好处:
-
策略模式(Strategy Pattern):
简单工厂可以创建策略模式中的各种策略对象。策略模式允许您在运行时根据不同的情境切换算法或策略。当结合简单工厂时,您可以隐藏创造这些策略的逻辑,简化策略的更换过程,进而使得客户代码在使用时,只需要关注策略接口而不是实现。 -
工厂方法模式(Factory Method Pattern):
虽然简单工厂模式不是工厂方法模式,但是它可以被视为是工厂方法模式的一种特例,当只有一个具体工厂类时。如果产品的创建逻辑比较简单,且不需要扩展额外的工厂类,使用简单工厂可能更为简便。 -
单例模式(Singleton Pattern):
简单工厂和单例模式可以结合起来用于确保特定类型只有一个实例被创建。例如,简单工厂可以返回应用程序中唯一的数据库连接实例或配置对象,从而保证资源的统一管理。 -
外观模式(Facade Pattern):
简单工厂可能被用于实现一个外观类的一部分,这个外观类提供了一个简化的接口,用于隐藏更复杂的子系统。外观模式经常与简单工厂一起使用,进一步简化客户端和子系统之间的交互。 -
适配器模式(Adapter Pattern):
当需要提供多个适配器类的实例时,简单工厂可以帮助创建这些类,无论是对象适配器还是类适配器,简单工厂都可以根据不同情况和需求来创建合适的适配器实例。 -
建造者模式(Builder Pattern):
在某些情况下,可以使用简单工厂来选择并创建具体的建造者实例。建造者模式通常用于创建复杂的对象,其中对象的创建过程需要多个步骤和过程。简单工厂可用于封装这一选择过程。
更多推荐
所有评论(0)