中介者模式定义了一个中介对象，该对象封装了系统中对象间的交互方式-CSDN博客

本文链接：https://blog.csdn.net/blog_programb/article/details/147852656

使用中介者（Mediator）设计模式来整合不同电子商务平台的支付接口是一个合理的解决方案。以下是中介者模式在这种场景下的一些关键点和实现步骤：

中介者模式概述

中介者模式定义了一个中介对象，该对象封装了系统中对象间的交互方式。中介者使各个对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。

应用场景

在电子商务平台的支付接口整合中，中介者模式可以帮助我们：

解耦支付接口：各个平台的支付接口不需要直接与调用它们的客户端交互，而是通过中介者进行交互。
统一接口：客户端只需要与中介者交互，而不需要关心具体的支付接口细节。
易于扩展：新增支付平台时，只需要在中介者中添加相应的逻辑，而不需要修改客户端代码。

实现步骤

定义中介者接口：
- 定义一个中介者接口，包含处理支付请求的方法。
实现具体中介者：
- 创建一个具体的中介者类，实现中介者接口。
- 在中介者类中，维护一个支付接口的映射关系，根据不同的请求调用相应的支付接口。
定义支付接口：
- 为每个电子商务平台定义一个支付接口，包含支付方法。
实现具体支付接口：
- 为每个电子商务平台实现具体的支付接口类，实现具体的支付逻辑。
客户端代码：
- 客户端代码只需要与中介者交互，通过中介者调用具体的支付接口。

示例代码

以下是一个简单的示例代码，展示如何使用中介者模式整合不同电子商务平台的支付接口：

// 支付接口
interface Payment {
    void pay(double amount);
}

// 具体支付接口实现
class Alipay implements Payment {
    public void pay(double amount) {
        System.out.println("通过支付宝支付：" + amount);
    }
}

class WeChatPay implements Payment {
    public void pay(double amount) {
        System.out.println("通过微信支付：" + amount);
    }
}

// 中介者接口
interface Mediator {
    void pay(double amount, Payment payment);
}

// 具体中介者实现
class PaymentMediator implements Mediator {
    private Map<String, Payment> payments = new HashMap<>();

    public void registerPayment(String name, Payment payment) {
        payments.put(name, payment);
    }

    public void pay(double amount, String paymentName) {
        Payment payment = payments.get(paymentName);
        if (payment != null) {
            payment.pay(amount);
        } else {
            System.out.println("支付方式不存在：" + paymentName);
        }
    }
}

// 客户端代码
public class Client {
    public static void main(String[] args) {
        PaymentMediator mediator = new PaymentMediator();
        mediator.registerPayment("Alipay", new Alipay());
        mediator.registerPayment("WeChatPay", new WeChatPay());

        mediator.pay(100, "Alipay");
        mediator.pay(200, "WeChatPay");
    }
}

总结

通过使用中介者模式，我们可以有效地整合不同电子商务平台的支付接口，使得客户端代码更加简洁和易于维护。同时，新增支付平台时，只需要在中介者中添加相应的逻辑，而不需要修改客户端代码。这种设计模式在多平台整合的场景中非常实用。
以下是使用中介者设计模式来整合不同电子商务平台支付接口的Python代码示例，模拟客户在不同平台购物时通过中介者来处理支付，而无需关心具体支付接口的过程：

class PaymentSystem:
    def pay(self, amount):
        pass


class PlatformA(PaymentSystem):
    def pay(self, amount):
        print(f"使用PlatformA支付了{amount}元")


class PlatformB(PaymentSystem):
    def pay(self, amount):
        print(f"使用PlatformB支付了{amount}元")


class Mediator:
    def __init__(self):
        self.platforms = {}

    def register(self, platform_name, platform):
        self.platforms[platform_name] = platform

    def pay(self, platform_name, amount):
        if platform_name in self.platforms:
            self.platforms[platform_name].pay(amount)
        else:
            print(f"未找到平台 {platform_name}")


# 示例使用
if __name__ == "__main__":
    mediator = Mediator()

    platform_a = PlatformA()
    platform_b = PlatformB()

    mediator.register("PlatformA", platform_a)
    mediator.register("PlatformB", platform_b)

    mediator.pay("PlatformA", 100)
    mediator.pay("PlatformB", 200)

在上述代码中：

PaymentSystem 是一个抽象类，定义了支付的接口 pay。
PlatformA 和 PlatformB 是具体的支付平台类，实现了 pay 方法，代表不同电子商务平台的支付接口。
Mediator 是中介者类，维护了一个平台字典，提供了 register 方法来注册平台，以及 pay 方法来通过中介者调用具体平台的支付功能。
在 main 函数中，创建了中介者对象、具体平台对象，并注册平台，最后通过中介者进行支付操作。

通过这种方式，客户在不同平台上购物时，只需要通过中介者来处理支付，而不需要关心具体的支付接口实现细节。
中介者模式是一种行为设计模式，它通过引入一个中介者对象来封装一系列对象之间的交互，使得这些对象之间的耦合度降低，从而提高系统的可维护性和可扩展性。以下是中介者模式的优缺点：

优点
- 降低耦合度：中介者模式将对象之间的多对多关系转化为对象与中介者之间的一对多关系，使得各个对象只需要与中介者进行交互，而不需要了解其他对象的具体情况，从而降低了对象之间的耦合度。例如，在一个聊天系统中，多个用户之间的聊天交互可以通过一个聊天中介者来处理，用户只需要将消息发送给中介者，中介者再将消息转发给相应的用户，这样用户之间就不需要直接相互引用，降低了耦合度。
- 提高可维护性和可扩展性：由于对象之间的耦合度降低，当需要对系统进行维护或扩展时，只需要修改中介者对象的代码，而不需要在多个相关对象中进行修改，从而提高了系统的可维护性和可扩展性。例如，在上述聊天系统中，如果要增加一种新的消息类型，只需要在聊天中介者中添加相应的处理逻辑，而不需要修改每个用户对象的代码。
- 便于复用：中介者对象可以被多个不同的对象复用，只要这些对象之间的交互逻辑可以通过该中介者来处理。例如，不同类型的用户（如普通用户、管理员等）在聊天系统中的交互都可以通过同一个聊天中介者来处理，提高了代码的复用性。
- 符合迪米特法则：迪米特法则要求一个对象应该对其他对象有尽可能少的了解，中介者模式使得对象之间的交互通过中介者来进行，对象只需要知道中介者，而不需要了解其他对象的内部细节，符合迪米特法则。
缺点
- 中介者对象可能变得复杂：当系统中的对象交互逻辑比较复杂时，中介者对象需要处理各种不同类型的交互，可能会导致中介者对象的代码变得庞大和复杂，难以理解和维护。例如，在一个复杂的企业信息系统中，涉及到多个部门（如销售部门、采购部门、生产部门等）之间的各种业务流程交互，这些交互都通过一个中介者来处理，可能会使中介者的代码难以管理。
- 可能存在性能问题：由于所有对象之间的交互都要通过中介者来进行，在一些性能要求较高的场景下，可能会导致性能下降。例如，在一个实时性要求很高的游戏系统中，大量游戏角色之间的交互通过中介者来处理，可能会增加消息传递的延迟，影响游戏的性能。
- 不符合开闭原则：如果要在系统中增加新的交互逻辑，可能需要修改中介者对象的代码，这在一定程度上违反了开闭原则（对扩展开放，对修改关闭）。例如，在聊天系统中，如果要增加一种新的聊天群组类型，可能需要在聊天中介者中添加相应的处理逻辑，修改中介者的代码。