面向对象与面向过程的本质区别在于数据与行为的绑定方式：前者通过实例封装状态并隐式传递，后者依赖显式参数传递且函数无状态。
面向对象的 new 和面向过程的 function 调用本质区别在哪
根本不在语法糖，而在数据与行为的绑定方式。面向对象中，new Person() 创建实例后，person.getName() 的执行依赖于该实例的字段状态（比如 name 是存在对象堆内存里的）；而面向过程写法如 getPersonName(personMap)，函数本身无状态，所有输入必须显式传参，输出也完全由输入决定。
常见误判是认为“用了类就是面向对象”，其实如果类里全是静态方法、不维护实例状态、也不用继承/多态，那只是披着类皮的面向过程。
- 面向对象天然支持封装：字段可设
private，通过方法控制访问路径 - 面向过程更易做纯函数测试：输入确定，输出就确定，不依赖外部变量或单例
- Java 中无法真正写出“纯”面向过程代码——连
main方法都得套在类里，但逻辑组织可以是过程式的
什么时候用 static 方法反而破坏了面向对象设计
当本该由对象承担的责任被抽成静态工具方法时，就退化了。比如 StringUtils.isEmpty(str) 合理，因为字符串操作不依赖某个特定字符串实例的状态；但写一个 OrderUtils.calculateDiscount(order) 就可疑——折扣逻辑往往和订单类型、用户等级、活动配置强相关，这些信息本该由 Order 或其子类自己封装。
典型坏味道：
立即学习“Java免费学习笔记（深入）”；
- 静态方法参数列表越来越长，开始传
Config、Logger、Cache等上下文 - 同一组静态方法反复操作同一组 Map/List 参数，实则是把对象字段手动“摊平”传参
- 为覆盖逻辑写多个重载静态方法，而本可用子类重写
calculate()
interface 不是面向对象的装饰品，而是解耦的关键开关
很多人把 interface 当作“为了用 Spring 注入才加的”，其实它定义的是能力契约，不是实现容器。比如声明 PaymentProcessor 接口，背后可以是 AlipayProcessor、MockProcessor 或 RetryWrapperProcessor，调用方只依赖接口，完全不知道具体实现里有没有网络请求、要不要重试、是否打日志。
对比面向过程做法：用 if (type.equals("alipay")) { ... } 硬编码分支，一旦新增支付方式就得改原逻辑，违反开闭原则。
- 接口方法不应包含状态字段，否则容易混淆“能力”和“实体”
- 默认方法（
default）适合提供通用模板逻辑，但别把它变成“伪继承” - 接口名优先用名词（
Printer）或能动词化名词（Authenticator），避免XXXUtil或XXXHelper
Java 8+ 的 Stream 和 Optional 是面向过程思维的强力补丁
它们不能替代面向对象，但能缓解 OOP 在数据流处理上的笨重感。比如遍历订单列表查未发货的：orders.stream().filter(o -> !o.isShipped()).map(Order::getId).collect(...) 比写个 UnshippedOrderFinder 类再 new 实例干净得多。
但这只是语法层优化，底层仍是对象——Stream 操作的对象还是 Order 实例，Optional 也只是对可能为空的引用做了类型标记。
- 别用
Optional包装返回集合或作为字段类型，它不是为持久化设计的 -
Stream适合一次性的数据转换，不适合复用复杂逻辑——这时该回到类封装 - 过度链式调用（5 层
.map().filter().flatMap()...）会让调试变困难，该拆就拆成带名字的中间变量
最常被忽略的一点：Java 的范式混用不是错误，而是现实。关键在于清楚每一层的职责——哪些状态必须由对象持有，哪些计算可以抽离为无状态函数，以及接口到底在隔离什么变化。写完一段代码，不妨自问：如果需求变一下（比如加个新订单类型），我得改几个地方？改得越散，说明抽象越弱。
