实体类代表事物本身，承载状态与身份，如User、Order；行为类专注做事，提供算法或协调能力，如PaymentProcessor、DiscountCalculator。区分关键在职责：实体被持有，行为被使用。
行为类和实体类的区分，关键看它“代表什么”以及“主要干什么”。实体类描述“事物本身”，行为类封装“事情怎么做”。别被名字绕晕，重点在职责和建模意图。
实体类：承载状态，对应现实/业务中的“东西”
实体类的核心是数据（属性）和与之强关联的、不可剥离的内聚行为。它有明确的身份（比如主键、ID），生命周期独立，状态可变且重要。
- 典型例子：User、Order、Product、BankAccount
- 特征：有ID字段（或自然标识）、常参与持久化、常被其他对象引用、属性多于方法、方法多为getter/setter或校验、计算等轻量逻辑（如user.isAdult()、order.getTotalAmount()）
- 注意：不是所有带属性的类都是实体类——如果一个类只是临时组装数据（如DTO、VO），没身份、不持久、不参与业务规则，那它属于传输类，不是实体类
行为类：专注做事，代表“能执行的动作”或“协作角色”
行为类不强调自身状态，而是提供算法、策略、协调、转换等能力。它可能无属性，或仅有配置类只读字段；它的价值在于“做了什么”，而不是“它是什么”。
- 典型例子：PaymentProcessor、DiscountCalculator、EmailNotifier、DataImporter
- 特征：方法多、属性少（甚至没有）、常实现接口（如PaymentService）、依赖注入其他对象（尤其是实体类）、常被Spring标记为@Service或@Component
- 常见误判：把UserService当成实体类——其实它是行为类（管理User的业务逻辑），而User才是实体类
边界模糊时，看建模目的和调用方式
有些类看似两头沾边，判断依据回归本质：这个类在系统里是被“当作对象来持有”，还是被“当作工具来使用”？
立即学习“Java免费学习笔记（深入）”；
- 如果你会写new Order().place()，那Order倾向是实体类（place是其内在行为）
- 如果你写的是orderService.placeOrder(order)，那orderService是行为类，order是传入参数（实体）
- 策略模式中的PricingStrategy：无ID、无持久状态、只做计算——纯行为类；哪怕它内部缓存了某些配置，只要不定义自身身份，就不算实体
基本上就这些。分清实体和行为，不是为了贴标签，而是让对象职责清晰、复用合理、扩展自然。建模时多问一句：“它活下来是为了被记住，还是为了把事干完？”答案往往就出来了。
