类职责应单一，避免“上帝类”；优先组合而非继承；字段默认private，谨慎暴露getter/setter；接口定义契约，抽象类提供共性实现；设计应映射业务稳定结构而非追求编码便利。
类职责是否单一，直接决定后续扩展成本
一个类只做一件事，是避免“上帝类”的第一道防线。比如处理用户登录的逻辑，不该同时包含密码加密、日志记录、邮件通知和数据库连接管理——这些应拆成 LoginService、PasswordEncoder、Logger、EmailNotifier 和 UserRepository 等独立类。
常见错误现象：UserManager 里塞了 800 行代码，修改短信发送逻辑时一并触发了登录失败计数器 bug。
- 判断标准：如果类名里带 “And”、“Or”、“With”，大概率职责过重（如
OrderProcessorWithLoggingAndRetry） - 重构信号：当新增一个功能需要在该类里加 if-else 分支、或引入新依赖时，就该考虑拆分
- 接口优先：先定义
AuthService接口，再写JwtAuthService或SessionAuthService实现，方便后期替换
继承 vs 组合？多数时候组合更安全
Java 中滥用 extends 是典型设计隐患。子类一旦继承父类，就强制绑定了其所有非私有行为和状态，哪怕只用其中 20% 的能力。
使用场景：只有当满足“is-a”关系且语义稳定时才用继承，例如 IOException 是 Exception 的一种；但 Car 不该继承 Engine（它不是发动机的一种），而应持有 Engine 实例。
立即学习“Java免费学习笔记（深入）”；
需要创建、读取、编辑或处理 Word 文档（.docx / .dotx）时使用。触发词：'Word'、'word 文档'、'.docx'、'生成报告'、'制作合同/简历/方案/说明书'、'提取 word 内容'、'在文档里查找替换'、'给文档加页眉页脚/目录/表格'。也用于把任意内容排版成一份正式的 Word 文件。不要用它处理 PDF、Excel 或无关编程任务。中文创作场景尤其适合：小说大纲稿、投稿文档、合同、简历、工作总结。
- 容易踩的坑：
ArrayList继承AbstractList是合理的，但你模仿它让ReportGenerator继承DataFetcher就会污染类型语义 - 组合示例：
public class ReportGenerator { private final DataFetcher dataFetcher; private final TemplateRenderer renderer; public ReportGenerator(DataFetcher fetcher, TemplateRenderer renderer) { this.dataFetcher = fetcher; this.renderer = renderer; } } - 性能影响：组合不带来额外运行时开销；而深继承链可能增加方法查找成本（虽 JVM 优化后不明显，但可读性代价更大）
哪些字段该设为 private，哪些该暴露为 getter/setter？
Java 类的封装不是靠加 private 就算完事，关键看外部是否真需要读/写这个值。盲目加 public 字段或无条件提供 setXXX()，等于主动放弃对内部状态的控制权。
常见错误现象：实体类里 private int age; 配了 setAge(int age)，结果外部传入 -5 导致业务逻辑崩溃。
- 原则：字段默认
private；仅当调用方明确需要读取时才加getXXX()；写操作优先走行为方法（如promoteToSenior()而非setLevel("SENIOR")） - 不可变对象优先：如
UserId、Money这类值对象，构造即定值，不提供 setter，避免被意外修改 - 集合字段要小心：
private List<string> tags;</string>的 getter 若直接返回原始引用，调用方tags.add("new")就破坏了封装 —— 应返回Collections.unmodifiableList(tags)
接口与抽象类怎么选？从“能做什么”出发，而非“是什么”
Java 8+ 后，接口也能有默认方法和静态方法，但它依然不是为了替代抽象类。核心区别在于：接口描述契约（what），抽象类描述共性实现（how）。
使用场景：Runnable、Comparable、AutoCloseable 都是典型接口——它们不关心你怎么实现，只约束你必须提供什么能力；而 HttpServlet 是抽象类，因为它提供了通用的 HTTP 方法分发逻辑，子类只需覆盖 doGet() 或 doPost() 即可。
- 容易踩的坑：为图省事把所有公共字段和工具方法都塞进接口，用
default实现，结果接口膨胀成“半抽象类”，丧失契约纯粹性 - 建议顺序：先定义接口（如
PaymentProcessor），再根据是否需要共享状态或模板逻辑，决定是否引入抽象基类（如AbstractPaymentProcessor） - 注意兼容性：给已有接口加新 default 方法基本安全；但加抽象方法会破坏所有实现类编译，慎之又慎
