OOP行为类与实体类区别详解

本文深入剖析了面向对象编程中行为类与实体类的本质区别：实体类代表具有唯一身份和持久状态的业务“事物”（如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才是实体类

边界模糊时，看建模目的和调用方式

有些类看似两头沾边，判断依据回归本质：这个类在系统里是被“当作对象来持有”，还是被“当作工具来使用”？

• 如果你会写new Order().place()，那Order倾向是实体类（place是其内在行为）
• 如果你写的是orderService.placeOrder(order)，那orderService是行为类，order是传入参数（实体）
• 策略模式中的PricingStrategy：无ID、无持久状态、只做计算——纯行为类；哪怕它内部缓存了某些配置，只要不定义自身身份，就不算实体

基本上就这些。分清实体和行为，不是为了贴标签，而是让对象职责清晰、复用合理、扩展自然。建模时多问一句：“它活下来是为了被记住，还是为了把事干完？”答案往往就出来了。

以上就是《OOP行为类与实体类区别详解》的详细内容，更多关于的资料请关注golang学习网公众号！