「面试官」: 您好！今天我们将探讨简单工厂模式。首先，您能解释一下什么是简单工厂模式吗？
「求职者」: 当然，简单工厂模式是一种创建对象的设计模式，「它通过一个单独的工厂类来决定实例化哪一个继承类。这个模式能够解决由接口隔离原则带来的一些问题，如选择合适的类进行实例化」。它能够使软件架构保持松耦合，同时具有良好的扩展性。
「面试官」: 了解了。那么，能否结合代码给我展示一下简单工厂模式是如何实现的？
「求职者」: 当然可以。以计算器程序为例，我们首先定义了一个操作类Operation，它拥有两个受保护的属性numberA和numberB，以及一个用于返回计算结果的getResult方法。
public class Operation {
protected double numberA = 0;
protected double numberB = 0;
public double getResult() {
double result = 0;
return result;
}
// ...其他getter和setter方法...
}
「面试官」: 那么，对于不同的运算操作，如何处理呢？
「求职者」: 我们可以创建不同的运算类来继承Operation类，并重写getResult方法。例如，对于加法运算，我们有OperationAdd类：
public class OperationAdd extends Operation {
@Override
public double getResult() {
return numberA + numberB;
}
}
「面试官」: 明白了。接下来，简单工厂类如何选择并创建具体的运算类实例？
「求职者」: 简单工厂类OperationFactory通过一个静态方法createOperate来实现。它根据传入的运算符参数来决定返回哪个具体的Operation子类实例。这是OperationFactory类的实现：
public class OperationFactory {
public static Operation createOperate(String operate) {
Operation operation = null;
switch (operate) {
case "+":
operation = new OperationAdd();
break;
// ...其他运算符的case...
default:
throw new RuntimeException("Unsupported operation");
}
return operation;
}
}
「面试官」: 了解了，那么客户端如何使用这个简单工厂类呢？
「求职者」: 客户端会根据「用户输入的数值和运算符号来获取相应的」Operation对象。然后设置输入的数值，并调用getResult方法来获取计算结果。这是一个控制台程序的例子：
public class CalculatorClient {
public static void main(String[] args) {
// ...获取输入的numberA、numberB和operationStr...
Operation operation = OperationFactory.createOperate(operationStr);
operation.setNumberA(numberA);
operation.setNumberB(numberB);
double result = operation.getResult();
System.out.println("结果为：" + result);
}
}
「面试官」: 很好。最后，您能谈谈简单工厂模式的优点和可能的缺点吗？
「求职者」: 简单工厂模式的优点是降低了客户端和具体类之间的耦合度，使得系统更容易扩展。只需添加新的运算类「并在工厂类中加入适当的逻辑即可」。缺点是当产品种类非常多时，工厂类可能会变得很复杂，并且如果增加新的产品，需要修改工厂类，这违反了开闭原则。
「面试官」: 在我们继续之前，你能给出一个实际的场景，说明在什么情况下会选择使用简单工厂模式吗？
「求职者」: 当然。假设我们正在开发一个电商平台，需要处理多种类型的支付方式，如信用卡支付、PayPal、银行转账等。「如果我们直接在代码中硬编码所有支付逻辑，每当添加新的支付方式时」，都需要修改原有代码，这会使代码变得难以维护和扩展。
在这种情况下，我们可以使用简单工厂模式创建一个支付工厂类，它负责根据不同的支付类型返回对应的支付对象。这样，每当我们需要添加新的支付方式时，只需添加一个新的支付类并在工厂类中增加相应的逻辑，而不需要修改任何现有代码。
「面试官」: 非常好。那么能否在这个场景中给出简单工厂模式的代码示例？
「求职者」: 当然可以。这是支付工厂类的代码示例：
public class PaymentFactory {
public static Payment createPayment(String paymentType) {
Payment payment = null;
switch (paymentType) {
case "CreditCard":
payment = new CreditCardPayment();
break;
case "PayPal":
payment = new PayPalPayment();
break;
case "BankTransfer":
payment = new BankTransferPayment();
break;
// ...其他支付方式...
default:
throw new RuntimeException("Unsupported payment method");
}
return payment;
}
}
每个支付方式如信用卡支付、PayPal支付等都会有对应的类，继承自Payment类，并实现具体的支付逻辑。
「面试官」: 能解释一下Payment类和一个具体支付类的实现吗？
「求职者」: 当然。Payment类是一个抽象类，它定义了所有支付方式共有的接口。例如，它可以有一个processPayment方法，用于处理支付。这是Payment类的一个简单实现：
public abstract class Payment {
public abstract void processPayment(double amount);
}
对于信用卡支付，我们可以有一个CreditCardPayment类，它实现了processPayment方法：
public class CreditCardPayment extends Payment {
@Override
public void processPayment(double amount) {
// 实现信用卡支付逻辑
System.out.println("Processing credit card payment for amount: " + amount);
}
}
「面试官」: 很好。你觉得在实际开发中，使用简单工厂模式会遇到哪些实际的挑战？
「求职者」: 实际开发中，最大的挑战可能是工厂类的扩展性问题。当新增很多支付方式时，工厂类可能会变得非常庞大，并且每次添加新的支付方式都需要修改工厂类，这违反了开闭原则。另外，如果支付方式的创建逻辑非常复杂，工厂类的代码也会变得复杂和难以维护。
「面试官」: 为了解决这些挑战，你会推荐使用哪种设计模式呢？
「求职者」: 如果我们想要遵守开闭原则，同时保持工厂类的简洁，「我们可以考虑使用工厂方法模式。在这种模式下，每个支付方式都有一个对应的工厂类，这些工厂类都实现了一个共同的接口」。这样，每当我们需要添加新的支付方式时，只需添加一个新的工厂类而不是修改现有的工厂类，这样就能保持工厂类的稳定和系统的可扩展性。
「面试官」: 很棒的建议。非常感谢今天的分享，这将是一个很有价值的面试。祝好运！
本文使用 markdown.com.cn 排版
