ThirdParty模块URS Request机制重构

任务时间: 2025年06月15日 11:36
任务类型: 代码重构
模块: ThirdParty
状态: ✅ 已完成

任务背景

ThirdParty模块的URS包存在Request机制设计问题，违反了"一个Request类只完成一种请求"的原则。原有的UrsRequest类使用switch语句处理多种操作，导致代码耦合度高、难以维护和扩展。

问题分析

重构前的问题

违反单一职责原则: 单个UrsRequest类处理register、deposit、withdraw、check等多种操作
代码耦合度高: 所有操作逻辑都在同一个类中，修改某个功能可能影响其他功能
难以维护和扩展: 新增功能需要修改现有类，测试困难
代码职责不清晰: 一个类承担了多种不同的请求处理责任

具体问题代码

protected function handler(array $params): array
{
    $action = $params['action'] ?? '';

    switch ($action) {
        case 'register':
            return $this->handleRegister($params);
        case 'deposit':
            return $this->handleDeposit($params);
        case 'withdraw':
            return $this->handleWithdraw($params);
        case 'check':
            return $this->handleCheck($params);
        default:
            throw new \Exception("不支持的操作类型: {$action}");
    }
}

解决方案

重构策略

采用"一个Request类只完成一种请求"的设计原则，将原有的单一Request类拆分为多个专用Request类。

实施步骤

1. 创建专用Request类

UrsGetUserInfoRequest.php - 专门处理获取用户信息请求
UrsGetUserTeamRequest.php - 专门处理获取用户团队关系请求
UrsGetUserLevelCountRequest.php - 专门处理获取用户下级统计请求
UrsRegisterRequest.php - 专门处理用户注册请求
UrsDepositRequest.php - 专门处理充值请求
UrsWithdrawRequest.php - 专门处理提取请求
UrsCheckBalanceRequest.php - 专门处理余额检查请求

2. 创建统一服务类

创建UrsService类来统一管理所有Request类的调用，提供简洁的API接口。

3. 更新服务提供者

修改UrsServiceProvider，注册新的服务类而不是旧的Request类。

4. 创建测试命令

新增TestUrsRequestCommand来验证重构后的功能。

实现细节

新增文件

ThirdParty/Urs/Request/
├── UrsGetUserInfoRequest.php       # 获取用户信息
├── UrsGetUserTeamRequest.php       # 获取用户团队关系
├── UrsGetUserLevelCountRequest.php # 获取用户下级统计
├── UrsRegisterRequest.php          # 用户注册
├── UrsDepositRequest.php           # 充值操作
├── UrsWithdrawRequest.php          # 提取操作
└── UrsCheckBalanceRequest.php      # 余额检查

ThirdParty/Urs/Services/
└── UrsService.php                  # 统一服务类

app/Module/ThirdParty/Commands/
└── TestUrsRequestCommand.php       # 测试命令

删除文件

ThirdParty/Urs/Request/UrsRequest.php (重命名为UrsRegisterRequest.php)

修改文件

ThirdParty/Urs/UrsServiceProvider.php - 更新服务注册
ThirdParty/Urs/readme.md - 更新文档说明
ThirdParty/README.md - 更新包开发规范
app/Module/ThirdParty/Providers/ThirdPartyServiceProvider.php - 注册测试命令

重构后的优势

1. 单一职责原则

每个Request类只负责一种特定的请求处理，代码职责清晰。

2. 易于维护

修改某个功能不会影响其他功能，代码隔离性好。

3. 易于扩展

新增功能只需创建新的Request类，不需要修改现有代码。

4. 易于测试

每个Request类可以独立测试，测试覆盖率更高。

5. 代码复用

通用逻辑在基类中实现，特定逻辑在各自的类中实现。

使用方式对比

重构前

$request = new UrsRequest();
$result = $request->request([
    'action' => 'userInfo',
    'userKey' => 'user_key_here'
]);

重构后

// 方式一：直接使用Request类
$request = new UrsGetUserInfoRequest();
$result = $request->request(['userKey' => 'user_key_here']);

// 方式二：使用统一服务类（推荐）
$result = UrsService::getUserInfo('user_key_here');

测试验证

测试命令

# 测试所有Request类
php artisan thirdparty:test-urs-request

# 测试特定类型
php artisan thirdparty:test-urs-request --type=userinfo
php artisan thirdparty:test-urs-request --type=team
php artisan thirdparty:test-urs-request --type=count
php artisan thirdparty:test-urs-request --type=register

测试结果

=== URS Request机制测试 ===
测试重构后的Request类设计

🔍 检查Request类是否存在...
  ✅ UrsGetUserInfoRequest 类存在
  ✅ UrsGetUserTeamRequest 类存在
  ✅ UrsGetUserLevelCountRequest 类存在
  ✅ UrsRegisterRequest 类存在

🔍 检查服务类是否存在...
  ✅ UrsService 类存在

✅ 测试完成

兼容性说明

本次重构是破坏性更新，不兼容旧的调用方式。如果有现有代码使用了旧的UrsRequest类，需要按照新的方式进行调整。

文档更新

更新了ThirdParty/Urs/readme.md，详细说明了新的Request机制
更新了ThirdParty/README.md，反映新的包开发规范
新增了Request机制重构说明.md，详细记录重构过程和设计思路

总结

本次重构成功解决了ThirdParty模块URS Request机制的设计问题，显著提高了代码的可维护性和扩展性。重构后的代码遵循单一职责原则，为后续的功能扩展奠定了良好的基础。

建议其他第三方包也采用类似的设计原则进行开发，确保代码质量和可维护性。

提交信息

Git提交: 4babfca9
提交信息: 重构ThirdParty模块URS Request机制
文件变更: 新增10个文件，修改4个文件，删除1个文件

151136-ThirdParty模块URS Request机制重构.md 5.9 KB Permalink History Raw