大工厂求职者必看！如何用简单工厂模式征服面试官

「面试官」: 您好！今天我们将探讨简单工厂模式。首先，您能解释一下什么是简单工厂模式吗？

「求职者」: 当然，简单工厂模式是一种创建对象的设计模式，「它通过一个单独的工厂类来决定实例化哪一个继承类。这个模式能够解决由接口隔离原则带来的一些问题，如选择合适的类进行实例化」。它能够使软件架构保持松耦合，同时具有良好的扩展性。

「面试官」: 了解了。那么，能否结合代码给我展示一下简单工厂模式是如何实现的？

「求职者」: 当然可以。以计算器程序为例，我们首先定义了一个操作类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 排版