类与对象是对真实业务角色的精准映射，需从职责、状态、行为出发设计；如Account封装取款校验、User负责密码验证、Order聚合商品并锁定库存，关系体现业务协作，避免失真建模。
类与对象不是抽象概念，而是对真实业务的精准映射。关键不在于“写几个类”，而在于“哪个现实角色该承担什么职责、保留什么状态、响应什么动作”。比如银行系统里，“账户”不是一串数字，而是有主人、有余额、能存能取、会拒绝非法操作的一个活的业务实体。
从现实角色出发定义类
别先想代码，先问自己：这个业务里有哪些独立参与方？它们各自有什么特征？会做什么事？
- “客户”有姓名、身份证号、联系方式——对应
User类的私有属性 - “商品”有编号、名称、价格、库存——对应
Product类的字段和getTotalPrice()方法 - “订单”本身不生产东西，但它聚合多个商品、记录创建时间、能算总价、可取消——这就是典型的组合关系，
Order类持有List<Product>，而不是把所有商品逻辑塞进去
用行为封装业务规则
对象的方法不是功能列表，而是它“被允许做的正当事情”。规则必须内聚在类内部，不能散落在main里。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 取款不能透支 →
Account.withdraw(double amount)方法内部校验if (amount > balance)，直接抛异常或返回失败标识 - 密码修改需原密码验证 →
User.changePassword(String oldPwd, String newPwd)方法里完成比对逻辑，外部调用者只管传参，不操心怎么验 - 订单生成后自动锁定库存 → 这个动作属于
Order的confirm()方法，而不是让InventoryService去“查订单再扣库存”
用关系表达业务协作
真实业务中没有孤岛。类之间的关系（关联、聚合、依赖）就是业务流程的骨架。
立即学习“Java免费学习笔记（深入）”；
- 一个
User可以拥有多个Account（一对多）→User类里维护List<Account> - 一个
Order由一个User发起，但不拥有该用户 →Order类里只存userId或引用User对象，不负责管理用户生命周期 -
PaymentService需要调用BankApi完成扣款 →PaymentService依赖BankApi接口，具体实现可替换（如模拟环境用MockBankApi）
避免常见失真建模
很多代码看起来是面向对象，实际仍是“换皮面向过程”，原因常出在以下几点：
- 把所有数据塞进一个
BankSystem类，再用一堆static方法操作——这等于把银行柜台、金库、监控室全交给一个保安干 - 属性全public，外部随意改余额、删账号——现实中没人能直接篡改银行账本，代码里也不该开放这种后门
- 方法命名像函数名（
calculateInterest()），却不属于任何主体——利息是谁的？是某个Account的，就该是它的实例方法
