Java为何推崇面向对象编程？

大家好，我们又见面了啊~本文《Java为何推崇面向对象编程》的内容中将会涉及到等等。如果你正在学习文章相关知识，欢迎关注我，以后会给大家带来更多文章相关文章，希望我们能一起进步！下面就开始本文的正式内容~

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“是一个折扣计算器”？逻辑崩坏。

• 优先用组合：把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会比十个零散函数更难维护。

到这里，我们也就讲完了《Java为何推崇面向对象编程？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！