类是抽象建模工具，需明确实体职责、清晰边界与协作；类名具体（如User/Order），避免Manager等泛化命名；对象创建重逻辑而非堆new；封装重契约轻细节；业务流程由对象自身或协作完成。
类与对象不是语法练习，而是建模工具。进阶的关键不在于多写几个 new，而在于让类真正承担起职责、让对象之间有清晰的边界和协作方式。
用类准确描述现实中的“东西”
类不是代码容器，是抽象建模的结果。比如处理“用户登录”，别急着写 LoginService，先问：系统里有哪些核心实体？答案通常是 User、AuthCode、Token、LoginLog。
- 每个实体单独建一个类，只放它该有的字段和方法。User 类里放 name、email、passwordHash，以及 changePassword()、isActive() 这类属于用户自身状态的方法
- 避免把“发短信”“查数据库”“写日志”塞进 User 类——这些动作不属于用户本身，而是外部服务行为
- 类名必须具体、可读，不用 Manager、Helper、Util 结尾；用 User、Order、PaymentRecord 这类名词
对象创建要讲逻辑，不靠堆 new
new 是手段，不是目的。什么时候该 new？什么时候不该？关键看“谁持有谁”“谁负责谁”。
- 一个订单对象（Order）创建后，它的商品列表（List<Item>）应该在构造时初始化，而不是等调用方传进来再 set
- 依赖外部服务（如发短信、存 Redis）的对象，不要在类内部 new SmsClient 或 Jedis；通过构造参数传入，实现解耦
- 避免在循环里反复 new 同一类对象——考虑复用、对象池，或改用 builder 模式控制构建过程
封装不是加 private 就完事
封装的本质是隐藏细节 + 暴露契约。private 只是第一步，重点在 getter/setter 是否必要、方法是否暴露了不该暴露的状态。
立即学习“Java免费学习笔记（深入）”；
- 如果某个字段只在类内部计算使用（如 orderTotal），就别提供 public setter，甚至不提供 getter，直接提供 getTotalAmount() 方法返回结果
- 集合类字段（如 List<String> tags）别直接返回引用，用 Collections.unmodifiableList 包装，防止外部误修改
- 构造器参数尽量用不可变类型（String、LocalDateTime），避免传入可变对象（如 Date、ArrayList）导致状态被意外篡改
从对象视角组织业务流程
告别“Service 方法里一串 if-else 调各种工具函数”。把流程责任交给对象本身或它们的协作关系。
- 比如“下单”动作，不是 OrderService.place(OrderDto)，而是 new Order(dto).confirm().save()，其中 confirm() 内部校验库存、扣减、生成单号
- 状态变化用状态模式或枚举驱动：OrderStatus.PAID、OrderStatus.SHIPPED，配合 canTransitionTo() 方法控制合法流转
- 多个对象协同完成一件事时，由发起者主动调用其他对象的方法，而不是 Service 层硬编码调用顺序（如 payment.process() → inventory.deduct() → notification.send()）
