在面向对象系统中，仅看行数和方法数量还不够。我们需要更精细的指标来评估一个类的设计质量。以下四个指标合称CK Metrics Suite（Chidamber & Kemerer），是业界公认的类复杂度评估标准。
（1）WMC（Weighted Methods per Class）
类的方法圈复杂度加权和
- 含义：一个类中所有方法的圈复杂度之和
- 示例：若某类有 5 个方法，圈复杂度分别为 6、8、5、12、4，则 WMC = 35
- 危害：WMC 越高，表示该类整体逻辑密度大，维护和测试成本高
- 建议阈值：≤45，否则应考虑拆分
WMC 是对“类长度”的深化 —— 它不仅看有多少方法，更关注这些方法有多复杂。
（2）CBO（Coupling Between Object Classes）
类间耦合度
- 含义：一个类所依赖的外部类的数量
- 关联概念：你在“依赖复杂度”一节中提到的Efferent Coupling（Ce）本质上就是 CBO
- 危害：CBO 高 → 耦合强 → 变动牵一发而动全身，不利于复用
- 建议阈值：≤7
小结：CBO 和 Efferent Coupling 指标一致，只是术语来源不同。现代工具如 SonarQube 使用后者，但在学术和架构评审中，“CBO”仍是通用说法。
（3）RFC（Response for a Class）
类的响应集
- 含义：一个类能直接或间接响应的方法总数，包括自身方法 + 它调用的外部方法
- 示例：
OrderService.create()调用了paymentService.pay()和rewardService.award()，则这两个调用也计入 RFC - 危害：RFC 越大，表示该类的行为影响面越广，测试组合爆炸，理解成本上升
- 建议阈值：≤50
（4）LCOM（Lack of Cohesion in Methods）
方法间内聚性缺失
- 含义：衡量类中方法是否共享相同的字段。如果方法分为几组，各自操作不同的属性，则 LCOM 高
class User { private String name, email; private int loginCount; // updateProfile() 只用 name/email // incrementLogin() 只用 loginCount // → LCOM 高，说明职责不聚焦 }- 危害：LCOM 高 → 类缺乏内聚性 → 实际上承担了多个职责 → 应拆分
- 改进方向：识别方法访问的字段簇，按业务边界进行类拆分
5. 继承结构复杂度
当系统使用继承时，还需关注类层次结构本身的复杂性。
（1）DIT（Depth of Inheritance Tree）
继承树深度
- 含义：从当前类到根类的最大路径长度
- 示例：
Animal → Mammal → Dog，Dog 的 DIT = 2 - 危害：DIT 越深，行为越难预测（父类逻辑隐式传递），调试困难
- 建议：DIT ≤ 3，过深应考虑改用组合
（2）NOC（Number of Children）
子类数量
- 含义：一个类的直接子类个数
- 危害：NOC 过大（如 >10）说明父类抽象不够通用，或继承体系设计不合理
- 改进方向：提取共性接口，或使用策略模式替代继承
6. 重复代码率（Duplication）
定义
系统中相同或高度相似代码块的比例。违背 DRY（Don't Repeat Yourself）原则。
实际案例：到处复制的签名逻辑
// 在 AlipayProcessor 中 String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase(); // 在 WechatPayProcessor 中（一模一样） String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase(); // 在 UnionpayProcessor 中（还是一样） String sign = DigestUtils.md5Hex(data + apiKey).toUpperCase();改进：提取公共服务
@Component public class SignatureService { public String sign(String data, String key) { return DigestUtils.sha256Hex(data + key).toUpperCase(); } }总结
| 层级 | 指标 | 推荐阈值 | 主要危害 |
|---|---|---|---|
| 方法级 | 圈复杂度 | ≤10 | 路径爆炸，难测试 |
| 嵌套深度 | ≤3 | 可读性差 | |
| 方法长度 | ≤50 行 | 职责不清 | |
| 类级 | 类长度 | ≤500 行 | 上帝类风险 |
| WMC | ≤45 | 整体逻辑密度过高 | |
| CBO / Ce | ≤7 | 耦合高，难维护 | |
| RFC | ≤50 | 行为泛滥，测试难 | |
| LCOM | 值越高越差 | 内聚不足，应拆分 | |
| 继承级 | DIT | ≤3 | 行为隐式传递 |
| NOC | 不宜过大 | 抽象不充分 | |
| 重复代码 | DRY | 不宜过多 | 不要重复自己 |
复杂度评估工具
要打赢复杂度战争，光靠人工 Code Review 远远不够。我们需要一套自动化的评估体系，在开发、提交、构建、部署的每个环节持续监控代码质量。
以下是目前 Java 生态中主流的复杂度评估方案与工具框架，它们可以单独使用，也可集成形成完整的质量门禁体系。
1. SonarQube：行业标准的静态分析平台
SonarQube 是目前最广泛使用的代码质量管理平台，支持对圈复杂度、重复率、代码坏味、测试覆盖率等指标进行可视化分析和阈值控制。
核心能力：
- 自动计算每个方法的圈复杂度，并标记 >10 的热点
- 检测重复代码块，支持跨文件识别
- 提供“技术债”估算：修复所有问题需要多少人天
- 支持 Quality Gate（质量门禁）：CI 中断机制
集成方式：
<!-- Maven 配置示例 --> <plugin> <groupId>org.sonarsource.scanner.maven</groupId> <artifactId>sonar-maven-plugin</artifactId> <version>3.9.1.2184</version> </plugin>执行扫描：
mvn sonar:sonar \ -Dsonar.projectKey=my-app \ -Dsonar.host.url=http://localhost:9000 \ -Dsonar.login=your-token推荐规则集：
cognitive-complexity：认知复杂度警告nested-if-else-depth：嵌套深度检测function-complexity：方法复杂度阈值duplicated-blocks：重复代码告警
2. IntelliJ IDEA 内置分析工具
IntelliJ 提供了强大的本地静态分析功能，开发者无需离开 IDE 即可发现复杂度问题。
由于 IDEA 迭代很快，使用方式各位开发同学可以自行搜索，
优点：即时反馈，适合在编码阶段预防问题。
3. PMD 与 Checkstyle：轻量级静态检查工具
两者常配合使用，用于 CI/CD 流水线中的自动化检查。
PMD 特点：
- 专注代码结构问题
- 内建规则：
ExcessiveMethodLength,CyclomaticComplexity,NestedIfDepth
具体使用方式不展开描述了，大家可以自行查阅。
4. ArchUnit：架构层面的依赖约束
ArchUnit 允许你用 Java 代码定义架构规则，防止模块间非法依赖。
5. GitHub Actions / Jenkins 集成：将复杂度检查纳入 CI
通过 CI 脚本自动运行分析工具，实现“不达标不合并”。
GitHub Actions 示例：
name: Code Quality on: [push, pull_request] jobs: sonar: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Set up JDK uses: actions/setup-java@v3 with: java-version: '17' - name: Run SonarQube Analysis run: mvn verify sonar:sonar -Dsonar.qualitygate.wait=true env: SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}当质量门禁失败时，PR 将被阻断，强制开发者先修复问题。
总结
| 工具 | 适用场景 | 关键能力 |
|---|---|---|
| SonarQube | 团队级质量管控 | 可视化 + 质量门禁 |
| IntelliJ | 个人开发阶段 | 实时提示 |
| PMD / Checkstyle | CI 自动化检查 | 规则驱动 |
| ArchUnit | 架构治理 | 依赖断言 |
| CI/CD 集成 | 流程卡点 | 强制合规 |
面向低复杂度的代码最佳实践
知道什么是复杂度还不够，关键是如何在日常编码中主动降低它。本着面向代码最佳实践的原则，尝试总结几条有效降低代码复杂的 Best Practise
原则一：单一职责
一个类或方法应该只做一件事。职责越清晰，修改影响面越小。
反例：多功能服务类
@Service public class OrderService { public void createOrder() { /* 创建 */ } public void sendNotification() { /* 发送通知 */ } public void calculateReward() { /* 计算积分 */ } public void logAudit() { /* 写审计日志 */ } }这个类承担了订单生命周期的多个角色，任何变更都可能引发副作用。
改进：按职责拆分
@Service public class OrderCreationService { ... } @Service public class OrderNotificationService { ... } @Service public class OrderRewardCalculationService { ... }职责分离后，各模块可独立测试、演进。
原则二：优先组合，而非继承
继承容易导致深层类层次结构，增加理解和维护成本。组合更灵活、更可控。
反例：继承滥用
class BasePaymentProcessor { } class AlipayProcessor extends BasePaymentProcessor { } class WechatPayProcessor extends BasePaymentProcessor { } class HybridAlipayProcessor extends AlipayProcessor { } // 多层继承子类隐式继承父类行为，难以预测执行逻辑。
改进：使用策略模式 + 组合
public interface PaymentStrategy { PaymentResult pay(BigDecimal amount); } @Service public class AlipayStrategy implements PaymentStrategy { ... } @Service public class WechatPayStrategy implements PaymentStrategy { ... } // 组合使用 public class UnifiedPaymentService { private final Map<String, PaymentStrategy> strategies; public UnifiedPaymentService(Map<String, PaymentStrategy> strategies) { this.strategies = strategies; } public PaymentResult pay(String type, BigDecimal amount) { return strategies.get(type).pay(amount); } }解耦清晰，扩展性强。
原则三：善用函数式编程减少状态污染
Java 8 引入的Optional和Stream不仅是语法糖，更是对抗复杂度的利器。
