Java强制代码写在类里是因OOP契约要求所有功能必须归属明确身份，如User类封装字段与方法；继承重在is-a关系而非复用；多态通过统一接口消除if-else分支；封装虽提升内聚却增加修改风险。
为什么Java强制要求写在类里？——不是设计选择，是语言契约
因为Java从诞生第一天起就规定：所有代码必须属于某个class。你写一个public static void main(String[] args)，也得套在class里。这不是“推荐做法”，而是编译器直接报错的硬性约束：class, interface, or enum expected。
这背后是OOP的底层契约：没有孤立的数据或函数，只有“谁拥有它、谁操作它”。比如User类封装name字段和login()方法，调用方只关心“用户登录”，不care密码怎么校验、token怎么生成——这些细节被private锁死在类内部。
- 新手常把工具方法全塞进
Utils类，结果变成“静态方法大杂烩”，违背封装本意 - 真正该复用的不是“功能”，而是“身份+行为”的组合，比如
PaymentService类既持有config属性，又提供pay()方法，后续换微信/支付宝只需替换实现类，不改调用方 - IDE重构时，重命名一个
class能自动更新所有引用；但重命名一个static方法，可能漏掉某处硬编码字符串调用
继承不是为了“省几行代码”，而是为了定义可替换的契约
Java只支持单继承，但extends的关键价值不在复用，而在明确“is-a”关系。比如class ElectronicBook extends Product，意味着任何接收Product参数的地方，都能安全传入ElectronicBook实例——这是Liskov替换原则的落地。
容易踩的坑是滥用继承：为复用一个getDiscount()方法，让Order去继承DiscountCalculator，结果Order“是一个折扣计算器”？逻辑崩坏。
立即学习“Java免费学习笔记（深入）”；
- 优先用组合：把
DiscountPolicy作为Order的字段，通过接口解耦 - 抽象类适合定义“有共同状态+部分默认行为”的场景，比如
AbstractList统一管理size字段和isEmpty()逻辑 - 子类重写方法时，别偷偷改变前置条件（比如父类允许
null输入，子类却抛NullPointerException），这是多态失效的根源
多态真正的威力：删掉if-else，而不是让代码看起来更“高级”
当业务需求变成“不同订单类型走不同支付流程”，面向过程会写一堆if (order.getType() == OrderType.VIP) { ... } else if (...) { ... }。而多态让你把判断逻辑下推到对象内部：order.pay()一句调用，自动路由到VIPOrder.pay()或NormalOrder.pay()。
这不只是语法糖——它让新增类型无需修改原有分支逻辑，符合开闭原则。但前提是：所有子类必须实现同一接口，且行为语义一致。
- 别用多态包装“本质上不同”的东西，比如让
FileLogger和DatabaseLogger都实现Logger接口没问题，但让Logger和PaymentService共用一个接口就荒谬 - 运行时类型判断（
instanceof）是多态的反模式，出现就得反思接口设计是否粒度太粗 - Spring里
@Autowired注入List，自动收集所有实现类，就是多态在框架层的自然延伸
封装最常被忽略的代价：它让“快速修复”变成高危操作
封装把数据和行为捆在一起，好处是调用方不用操心内部细节；坏处是当你发现某个private方法有bug，想临时打补丁时，可能得动整个类的逻辑链——因为它的状态可能被多个public方法共享。
比如Order类里private BigDecimal total被addProduct()、applyCoupon()、calculateTax()反复修改，改其中一个方法的计算逻辑，可能意外影响其他方法的结果。
- 把状态变更集中到少数几个
public入口，避免“到处改一点” - 用不可变对象（
final字段 + 无setter）降低状态风险，比如LocalDateTime比Date更安全 - 单元测试要覆盖所有公开方法的组合路径，而不是只测单个方法——封装让边界变少，但内部路径变深
面向对象不是银弹，它把复杂性从“散落各处”收束到“类的边界内”。你省下的不是代码行数，而是理解成本和修改风险。但收束本身需要设计克制，否则一个失控的God Class会比十个零散函数更难维护。
