《clean code》面向对象规范强调可读、可维护、可测试：类要小且职责单一，命名准确；函数短小、单一层级抽象；多态优于条件分支；隐藏实现细节，暴露意图。

遵循《Clean Code》中的面向对象规范，核心是让代码更可读、可维护、可测试——不是堆砌设计模式，而是用最自然的方式表达意图。

类要小，职责单一

一个类只做一件事，并把这件事做好。判断标准：修改它的理由应该只有一个。比如 User 类负责用户数据结构和基础验证，UserRepository 负责持久化，UserService 负责业务流程——不把数据库操作塞进 User 类里，也不在 Service 里拼 SQL。

• 类名应是名词，准确反映其本质（如 PaymentProcessor，而非 DoPaymentStuff）
• 方法数通常不超过 10 个；超过就考虑拆分或提取新类
• 构造函数参数尽量控制在 3 个以内，多则用 Builder 或配置对象封装

函数是动词，短小且只做一层抽象

每个函数只表达一个清晰的“步骤”，且所有语句应在同一抽象层级。避免一边调用 saveToDatabase()，一边又写 if (user.email.contains("@"))——前者是高层动作，后者是底层细节，混在一起会模糊意图。

• 函数长度最好不超过 20 行；超过就要问：是否能提取出更小、命名明确的函数？
• 返回值类型明确，避免返回 null；优先用 Optional、空集合或特例对象（如 NoUserFound）
• 布尔函数命名用肯定式（isEligibleForDiscount() 而非 isNotIneligible()）

多态优于条件分支

当看到一长串 if-else 或 switch 判断类型并执行不同逻辑时（比如按支付方式走不同流程），说明行为差异该由子类或策略对象承担，而不是靠硬编码分支来控制。

• 把变化点封装成接口（如 PaymentStrategy），让 CreditCardPayment、PayPalPayment 各自实现
• 工厂或依赖注入容器负责创建具体实例，主流程只依赖接口
• 这样新增一种支付方式，只需加一个类，无需改原有判断逻辑

隐藏实现细节，暴露意图而非机制

调用者不该知道你用了 HashMap 还是 TreeMap，也不该关心你是发 HTTP 请求还是查本地缓存——这些是内部决策。对外只暴露“做什么”，不暴露“怎么做”。

• 成员变量尽量 private；设为 public 的字段几乎总是坏味道
• 避免 getter/setter 泛滥；如果需要暴露状态，考虑提供有业务含义的方法（如 user.promoteToPremium() 比 user.setRole("PREMIUM") 更清晰）
• 构造函数或工厂方法应确保对象创建后即处于有效状态（不变量成立）