pojo（plain old java Object）并非一个严格的正式定义，它代表的是不被复杂框架深度耦合的简单Java对象。pojo可以包含业务逻辑，尤其与自身内部状态管理及对外交互相关的逻辑，这与将其用作领域对象（domain object）的架构模式相符。虽然通常避免大量外部框架注解，但特定如bean validation等仍可接受。java records是pojo的一种现代演进，用于简洁地表达不可变数据。
POJO的本质：去框架化与简洁性
POJO这一术语由Martin Fowler、Rebecca Parsons和Josh macKenzie于2000年提出，旨在与当时Java EE中重量级的EJB Entity Beans形成对比。其核心思想是，一个POJO应该是不被复杂框架深度耦合的普通Java对象。这意味着任何有经验的java开发者都应该能够轻松理解其源代码，而无需学习特定的框架或查阅大量第三方文档。POJO的定义并非严格的规范，而是一种设计哲学，强调对象的独立性、可测试性和简洁性。
POJO与注解：选择的艺术
由于POJO旨在避免复杂框架的纠缠，它通常会尽量减少对外部框架注解的依赖。大多数注解来源于外部框架，因此，避免外部框架意味着减少了大多数注解的使用。
然而，这并非绝对。某些特定类型的注解，如果它们专注于POJO自身的内部状态验证或管理，并且不会导致复杂的外部协调，则可以被视为可接受的例外。例如：
- Jakarta Bean Validation： 这是一个相对简单的框架，其注解（如@NotNull、@Size）直接作用于POJO的字段，用于定义数据的有效性规则，而不涉及复杂的运行时交互。
- 日志框架： 用于日志记录的注解（如SLF4J或log4j的特定注解）通常也只影响POJO的日志行为，不改变其核心业务逻辑。
- Java Management Extensions (JMX)： 用于监控和管理的JMX注解，如果它们主要关注POJO自身的运行时属性，也可以被谨慎使用。
这些例外都围绕着一个共同点：它们增强了POJO的内部功能或可观测性，而不是将其与外部系统的复杂流程紧密绑定。
立即学习“Java免费学习笔记（深入）”；
POJO中的业务逻辑：领域对象的实践
关于POJO是否可以包含业务逻辑，答案是肯定的。POJO完全可以包含业务逻辑，尤其是那些与其自身内部状态管理、数据完整性维护以及与外部世界（如数据持久化、事件通知）通信相关的逻辑。
在现代软件架构中，POJO常被用作领域对象（Domain Object），它们封装了核心业务规则和行为。例如，在以下架构模式中，POJO扮演着关键角色：
- 六边形架构（Hexagonal Architecture）/端口和适配器模式： 在这种架构中，核心业务逻辑（由POJO组成的领域模型）位于中心，通过“端口”定义其接口，并通过“适配器”与外部技术（如数据库、ui、消息队列）进行交互。POJO在此模型中保持纯粹，不依赖于任何特定的外部技术。
- 领域驱动设计（Domain-Driven Design, DDD）： DDD强调将业务领域模型作为软件设计的核心。POJO在此扮演“实体”或“值对象”的角色，它们不仅携带数据，更重要的是封装了领域行为和业务规则。
通过这些模式，我们可以将POJO作为核心业务逻辑的载体，同时将其与各种复杂的框架（如Web框架、ORM框架）隔离开来，从而保持其简洁性、可测试性和独立性。
示例：一个带有业务逻辑的POJO
考虑一个Order（订单）POJO，它不仅包含订单数据，还包含更改订单状态的业务逻辑：
import java.math.BigDecimal; import java.time.LocalDateTime; import java.util.ArrayList; import java.util.List; import java.util.Objects; public class Order { private Long id; private String customerId; private LocalDateTime orderDate; private OrderStatus status; private List<OrderItem> items; private BigDecimal totalAmount; public Order(Long id, String customerId, LocalDateTime orderDate) { this.id = id; this.customerId = customerId; this.orderDate = orderDate; this.status = OrderStatus.PENDING; // 初始状态 this.items = new ArrayList<>(); this.totalAmount = BigDecimal.ZERO; } // Getter methods public Long getId() { return id; } public String getCustomerId() { return customerId; } public LocalDateTime getOrderDate() { return orderDate; } public OrderStatus getStatus() { return status; } public List<OrderItem> getItems() { return new ArrayList<>(items); } // 返回副本以保证不可变性 public BigDecimal getTotalAmount() { return totalAmount; } // Business logic methods public void addItem(OrderItem item) { Objects.requireNonNull(item, "Order item cannot be null"); if (status != OrderStatus.PENDING) { throw new IllegalStateException("Cannot add items to an order that is not PENDING."); } this.items.add(item); this.totalAmount = this.totalAmount.add(item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity()))); } public void placeOrder() { if (status != OrderStatus.PENDING) { throw new IllegalStateException("Only PENDING orders can be placed."); } if (items.isEmpty()) { throw new IllegalStateException("Cannot place an empty order."); } this.status = OrderStatus.PLACED; // 可以在这里触发事件通知或进行其他业务操作 System.out.println("Order " + id + " placed successfully."); } public void cancelOrder() { if (status == OrderStatus.DELIVEred || status == OrderStatus.CANCELLED) { throw new IllegalStateException("Cannot cancel an order that is DELIVERED or already CANCELLED."); } this.status = OrderStatus.CANCELLED; // 可以在这里处理退款逻辑等 System.out.println("Order " + id + " cancelled."); } // Enum for Order Status public enum OrderStatus { PENDING, PLACED, SHIPPED, DELIVERED, CANCELLED } // Nested POJO for OrderItem public static class OrderItem { private String productId; private int quantity; private BigDecimal price; public OrderItem(String productId, int quantity, BigDecimal price) { this.productId = productId; this.quantity = quantity; this.price = price; } // Getter methods for OrderItem public String getProductId() { return productId; } public int getQuantity() { return quantity; } public BigDecimal getPrice() { return price; } } }
在这个例子中，Order POJO不仅有id、customerId等数据字段，还包含了addItem、placeOrder和cancelOrder等业务方法，这些方法封装了订单状态变更的规则。
数据传输对象（DTO）与值对象（Value Object）
并非所有POJO都必须包含复杂的业务逻辑。有些POJO的主要目的是简单地承载数据。这类POJO包括：
- 数据传输对象（Data Transfer Object, DTO）： DTO主要用于在不同层之间（如Web层与服务层）传输数据。它们通常只包含字段和对应的getter/setter方法，没有或极少有业务逻辑。
- 值对象（Value Object）： 值对象代表一个概念上的整体，它们通常是不可变的，并且通过其属性值来定义其相等性（例如，一个Address对象，两个地址如果所有字段都相同，则它们是相等的）。值对象也主要承载数据，但可能包含一些简单的验证或格式化逻辑。
所有数据传输对象和值对象都是POJO，但反之不然——一个POJO可以包含更丰富的业务行为。
Java Records：现代POJO的简洁表达
自Java 16起引入的records特性，为透明地传递浅层不可变数据提供了一种更简洁、更安全的方式。Records本质上也是POJO，但它们通过编译器隐式生成构造函数、访问器（getter）、equals()、hashCode()和toString()方法，极大地减少了样板代码。
示例：使用Record定义数据对象
import java.time.LocalDate; public record Employee(String firstName, String lastName, LocalDate hired) { // Records可以有紧凑构造函数或自定义方法，但通常用于简洁的数据持有 public String getFullName() { return firstName + " " + lastName; } }
Records非常适合作为DTO或简单的值对象，它们强调数据的不可变性和透明性。
总结
POJO的概念强调的是解耦和简洁。它不是为了排斥所有框架，而是为了区分那些独立、易于理解的核心业务对象与那些深度依赖特定框架的对象。理解POJO的真正含义，能够帮助开发者构建更健壮、更灵活、更易于维护的软件系统。在适当的架构模式下，POJO不仅可以承载数据，更能成为封装核心业务逻辑的强大工具。