java面向对象三大特性是协同解决设计问题的思维工具:封装管控数据边界与业务规则,继承表达is-a层级关系,多态支持行为扩展与解耦;三者联动如优惠券系统中,coupon封装校验逻辑,子类继承实现差异化计算,promotionengine通过多态统一调用。

Java面向对象核心特性不是孤立存在的语法点,而是协同解决真实设计问题的一套思维工具。封装管住数据边界,继承理清类型关系,多态支撑行为扩展——三者配合得当,代码才真正具备可维护、易演进的结构基础。
用封装定义“谁该负责什么”
封装不只是加private和getter/setter。它的关键是把业务规则和状态约束收归到类内部,让对象自己管理自己的合法性。
- 比如订单金额不能为负、状态流转必须符合流程(待支付→已支付→已完成),这些逻辑不应散落在Service里反复判断,而应写在Order类的pay()、cancel()等方法中
- 字段设为private后,提供的是受控操作接口,不是无脑访问通道。像setAmount(double)这种暴露式方法,往往不如confirmPayment(long paidCent)这样的业务动作语义清晰
- 构造器就做初始化校验,避免new出非法对象;final修饰不可变字段,从源头减少意外修改
用继承表达“是什么”的层级关系
继承适用于强“is-a”语义的场景,比如Employee是Person的一种,SavingsAccount是BankAccount的一种。它解决的是共性抽取与自然分类问题。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 父类定义通用属性(name、id)和稳定行为(printInfo()),子类专注特有逻辑(Manager的approveLeave()、SavingsAccount的calculateInterest())
- 避免为了复用代码而强行继承。若只是“有某种能力”,优先考虑组合或接口实现。例如邮件发送功能,与其让Order继承EmailSender,不如让Order持有MailService实例
- 注意Java单继承限制。当需要多个能力时,用接口(如Payable、Shippable、Loggable)+ 实现类组合更灵活
用多态驱动“怎么变”的扩展机制
多态让调用方不依赖具体类型,只面向抽象编程。这是应对需求变化最有效的解耦手段。
- 策略模式是典型应用:支付方式(Alipay、WechatPay、CardPay)都实现Payment接口,OrderService只需调用payment.process(),新增支付渠道无需改已有代码
- 模板方法模式也依赖多态:AbstractOrderProcessor定义execute()流程骨架,子类重写validate()、persist()、notify()等钩子方法,主流程不变,细节可插拔
- Spring中大量使用多态:@Autowired注入接口类型,容器自动装配具体实现;MyBatis的SqlSession、Mapper接口背后也是动态代理多态实现
三者联动的真实协作链路
一个电商优惠券系统能体现三者如何咬合:
- 封装:Coupon基类私有管理有效期、使用门槛、折扣值,并提供canUse(Order order)统一校验入口
- 继承:FixedAmountCoupon、PercentageCoupon、FreeShippingCoupon分别继承Coupon,各自实现applyTo(Order order)计算逻辑
- 多态:PromotionEngine持有一个List
,遍历时统一调用coupon.applyTo(order),不关心具体是哪种券
这样设计后,加一种新券类型只需新增一个子类并注册进列表,其他模块零改动。
Java免费学习笔记:立即使用
解锁 Java 大师之旅:从入门到精通的终极指南










