Initial commit

2025-11-30 09:05:46 +08:00
commit a64cee7b84
51 changed files with 11796 additions and 0 deletions
--- a/commands/design-patterns.md
+++ b/commands/design-patterns.md
@@ -0,0 +1,186 @@
+## 设计模式
+
+提出可应用于代码库的设计模式，评估 SOLID 原则的遵守情况。
+
+### 使用方法
+
+```bash
+/design-patterns [分析对象] [选项]
+```
+
+### 选项
+
+- `--suggest` : 提出可应用的模式 (默认)
+- `--analyze` : 分析现有模式的使用情况
+- `--refactor` : 生成重构方案
+- `--solid` : 检查 SOLID 原则的遵守情况
+- `--anti-patterns` : 检测反模式
+
+### 基本示例
+
+```bash
+# 整个项目的模式分析
+/design-patterns
+
+# 对特定文件提出模式建议
+/design-patterns src/services/user.js --suggest
+
+# SOLID 原则检查
+/design-patterns --solid
+
+# 反模式检测
+/design-patterns --anti-patterns
+```
+
+### 分析类别
+
+#### 1. 创建型模式
+
+- **Factory Pattern**: 对象创建的抽象化
+- **Builder Pattern**: 复杂对象的分步构建
+- **Singleton Pattern**: 保证实例的唯一性
+- **Prototype Pattern**: 对象的克隆生成
+
+#### 2. 结构型模式
+
+- **Adapter Pattern**: 接口转换
+- **Decorator Pattern**: 动态添加功能
+- **Facade Pattern**: 简化复杂子系统
+- **Proxy Pattern**: 对象访问控制
+
+#### 3. 行为型模式
+
+- **Observer Pattern**: 事件通知的实现
+- **Strategy Pattern**: 算法切换
+- **Command Pattern**: 操作封装
+- **Iterator Pattern**: 集合遍历
+
+### SOLID 原则检查项
+
+```text
+S - Single Responsibility Principle (单一职责原则)
+O - Open/Closed Principle (开闭原则)
+L - Liskov Substitution Principle (里氏替换原则)
+I - Interface Segregation Principle (接口隔离原则)
+D - Dependency Inversion Principle (依赖倒置原则)
+```
+
+### 输出示例
+
+```text
+设计模式分析报告
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+当前使用的模式
+├─ Observer Pattern: EventEmitter (12 处)
+├─ Factory Pattern: UserFactory (3 处)
+├─ Singleton Pattern: DatabaseConnection (1 处)
+└─ Strategy Pattern: PaymentProcessor (5 处)
+
+推荐模式
+├─ [HIGH] Repository Pattern
+│  └─ 对象: src/models/*.js
+│  └─ 原因: 分离数据访问逻辑
+│  └─ 示例:
+│      class UserRepository {
+│        async findById(id) { ... }
+│        async save(user) { ... }
+│      }
+│
+├─ [MED] Command Pattern
+│  └─ 对象: src/api/handlers/*.js
+│  └─ 原因: 统一请求处理
+│
+└─ [LOW] Decorator Pattern
+   └─ 对象: src/middleware/*.js
+   └─ 原因: 改进功能组合
+
+SOLID 原则违反
+├─ [S] UserService: 同时负责认证和权限管理
+├─ [O] PaymentGateway: 添加新支付方式需要修改
+├─ [D] EmailService: 直接依赖具体类
+└─ [I] IDataStore: 包含未使用的方法
+
+重构建议
+1. 将 UserService 拆分为认证和权限管理
+2. 引入 PaymentStrategy 接口
+3. 定义 EmailService 接口
+4. 按用途拆分 IDataStore
+```
+
+### 高级用法
+
+```bash
+# 模式应用的影响分析
+/design-patterns --impact-analysis Repository
+
+# 生成特定模式的实现示例
+/design-patterns --generate Factory --for src/models/Product.js
+
+# 模式组合建议
+/design-patterns --combine --context "带缓存的 API"
+
+# 架构模式评估
+/design-patterns --architecture MVC
+```
+
+### 模式应用示例
+
+#### Before (有问题的代码)
+
+```javascript
+class OrderService {
+  processOrder(order, paymentType) {
+    if (paymentType === "credit") {
+      // 信用卡处理
+    } else if (paymentType === "paypal") {
+      // PayPal 处理
+    }
+    // 其他支付方式...
+  }
+}
+```
+
+#### After (应用 Strategy Pattern)
+
+```javascript
+// 策略接口
+class PaymentStrategy {
+  process(amount) {
+    throw new Error("必须实现 process 方法");
+  }
+}
+
+// 具体策略
+class CreditCardPayment extends PaymentStrategy {
+  process(amount) {
+    /* 实现 */
+  }
+}
+
+// 上下文
+class OrderService {
+  constructor(paymentStrategy) {
+    this.paymentStrategy = paymentStrategy;
+  }
+
+  processOrder(order) {
+    this.paymentStrategy.process(order.total);
+  }
+}
+```
+
+### 反模式检测
+
+- **God Object**: 承担过多职责的类
+- **Spaghetti Code**: 控制流复杂纠缠的代码
+- **Copy-Paste Programming**: 过度使用重复代码
+- **Magic Numbers**: 硬编码的常量
+- **Callback Hell**: 深度嵌套的回调
+
+### 最佳实践
+
+1. **渐进式应用**: 不要一次应用太多模式
+2. **必要性验证**: 模式是解决问题的手段而非目的
+3. **团队共识**: 应用模式前团队讨论
+4. **文档化**: 记录应用模式的意图