|
|
@@ -0,0 +1,184 @@
|
|
|
+# ThirdParty模块URS Request机制重构
|
|
|
+
|
|
|
+**任务时间**: 2025年06月15日 11:36
|
|
|
+**任务类型**: 代码重构
|
|
|
+**模块**: ThirdParty
|
|
|
+**状态**: ✅ 已完成
|
|
|
+
|
|
|
+## 任务背景
|
|
|
+
|
|
|
+ThirdParty模块的URS包存在Request机制设计问题，违反了"一个Request类只完成一种请求"的原则。原有的`UrsRequest`类使用switch语句处理多种操作，导致代码耦合度高、难以维护和扩展。
|
|
|
+
|
|
|
+## 问题分析
|
|
|
+
|
|
|
+### 重构前的问题
|
|
|
+1. **违反单一职责原则**: 单个`UrsRequest`类处理register、deposit、withdraw、check等多种操作
|
|
|
+2. **代码耦合度高**: 所有操作逻辑都在同一个类中，修改某个功能可能影响其他功能
|
|
|
+3. **难以维护和扩展**: 新增功能需要修改现有类，测试困难
|
|
|
+4. **代码职责不清晰**: 一个类承担了多种不同的请求处理责任
|
|
|
+
|
|
|
+### 具体问题代码
|
|
|
+```php
|
|
|
+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. 代码复用
|
|
|
+通用逻辑在基类中实现，特定逻辑在各自的类中实现。
|
|
|
+
|
|
|
+## 使用方式对比
|
|
|
+
|
|
|
+### 重构前
|
|
|
+```php
|
|
|
+$request = new UrsRequest();
|
|
|
+$result = $request->request([
|
|
|
+ 'action' => 'userInfo',
|
|
|
+ 'userKey' => 'user_key_here'
|
|
|
+]);
|
|
|
+```
|
|
|
+
|
|
|
+### 重构后
|
|
|
+```php
|
|
|
+// 方式一：直接使用Request类
|
|
|
+$request = new UrsGetUserInfoRequest();
|
|
|
+$result = $request->request(['userKey' => 'user_key_here']);
|
|
|
+
|
|
|
+// 方式二：使用统一服务类（推荐）
|
|
|
+$result = UrsService::getUserInfo('user_key_here');
|
|
|
+```
|
|
|
+
|
|
|
+## 测试验证
|
|
|
+
|
|
|
+### 测试命令
|
|
|
+```bash
|
|
|
+# 测试所有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`类，需要按照新的方式进行调整。
|
|
|
+
|
|
|
+## 文档更新
|
|
|
+
|
|
|
+1. 更新了`ThirdParty/Urs/readme.md`，详细说明了新的Request机制
|
|
|
+2. 更新了`ThirdParty/README.md`，反映新的包开发规范
|
|
|
+3. 新增了`Request机制重构说明.md`，详细记录重构过程和设计思路
|
|
|
+
|
|
|
+## 总结
|
|
|
+
|
|
|
+本次重构成功解决了ThirdParty模块URS Request机制的设计问题，显著提高了代码的可维护性和扩展性。重构后的代码遵循单一职责原则，为后续的功能扩展奠定了良好的基础。
|
|
|
+
|
|
|
+建议其他第三方包也采用类似的设计原则进行开发，确保代码质量和可维护性。
|
|
|
+
|
|
|
+## 提交信息
|
|
|
+
|
|
|
+**Git提交**: 4babfca9
|
|
|
+**提交信息**: 重构ThirdParty模块URS Request机制
|
|
|
+**文件变更**: 新增10个文件，修改4个文件，删除1个文件
|
notfff