1. 从复制代码到设计代码：类和对象思维到底转变在哪
1.1 先别背定义，看看类和对象在业务里长什么样
我在带新人或者帮同事review代码的时候，经常遇到一种情况：刚学Java的人能把"类是抽象模板，对象是具体实例"这句话背得滚瓜烂熟，但让他写一个实际业务模块，写出来的代码却跟类设计没有太大关系——所有逻辑堆在main方法里，或者一个类写了上千行，字段全是public，方法动不动就几百行。这种状态说明什么？说明类和对象的定义，并没有真正转化为设计思维。
我们可以先放下教科书术语，用一个特别贴近业务的场景来理解。假设你的系统里要处理"用户订单"这个概念。一个订单有什么？订单号、下单时间、商品列表、总金额、收货地址、用户ID，这些是订单的属性。订单能做什么？计算总价、修改收货地址、取消订单、查询状态，这些是订单的行为。在面向过程的写法里，你会定义一堆散落的变量和一个函数，调用时不断把变量传来传去。但订单本身在你的代码里是没有一个"载体"的，它分裂在十几个变量和参数之间。
类要解决的，正是这个问题。你把"订单"这个业务概念定义成一个类，把属性和行为收拢在一起，它就成了一个可以反复使用的模板。每次真实产生一单交易，你基于这个模板创建一个具体的订单对象，填上真实的数据，调用它的行为方法。这就是"类"和"对象"在业务里的原始含义——模板与成品的关系，定义与实例的关系。
1.2 Java为什么把类当作一切的基础，而不是函数
C语言时代，程序的组织单位是函数。一个程序就是一堆函数按执行顺序互相调用。这种方式写小工具没问题，但一旦业务复杂起来，函数的参数列表会失控，全局变量会越来越多，改一处逻辑可能要牵连好几个函数。Java的设计者们做了一个关键决策：一切代码都必须放在类里，Java程序的起点——main方法——本身也必须是某个类的成员方法。
这个约束表面看像是限制，实际上是在强制你思考：这段数据处理逻辑，本质上属于哪个业务概念？这个概念应该承担哪些职责？你还没开始写代码，就得先想清楚这个问题。我自己多年的体会是，这种强制约束的长期价值，远比它带来的那点学习成本大。因为它逼着你在代码规模还不大的时候就建立模块化意识，而不是等代码膨胀到没法收拾的地步再返工。
Java中类的定义有一些硬性规则，新手容易忽略。一个源文件里可以定义多个类，但public修饰的类必须与文件名同名，而且一个源文件最多只能有一个public类。这个规则跟Java的编译机制有关——编译器需要根据public类的名字找到对应的字节码文件。另外，Java的类名约定使用大驼峰命名法（OrderDetail、UserAccount），这不仅是代码规范问题，更是可读性和协作效率的基础。
1.3 从最小完整类入手，理解结构的必要组成
一个最基本的类，至少要包含两个部分：成员变量（字段）和成员方法。字段描述状态，方法描述行为。我给你一个贴近日常业务的例子：
public class Order { // 字段：描述订单的状态 private String orderId; private long createTime; private BigDecimal totalAmount; private String status; // 方法：描述订单的行为 public void cancel() { if ("PAID".equals(status) || "CREATED".equals(status)) { this.status = "CANCELLED"; System.out.println("订单" + orderId + "已取消"); } else { System.out.println("当前状态不可取消"); } } public BigDecimal calculateDiscount(BigDecimal rate) { return totalAmount.multiply(rate); } }注意这里面有个细节：字段是private的，外部不能直接改，要改只能通过方法。这就是封装。你想想真实业务，订单状态能随便被外部直接赋值吗？如果哪里都能直接改status导致状态乱跳，那订单数据就废了。通过cancel方法统一处理，就可以在方法里写清楚状态流转规则，这是类设计对业务逻辑的第一层保护。
用这个最简单的代码为底子，我后续再展开字段、方法、构造、内存这些细节，你会更容易串起来。
2. 类的构建细节：字段、方法与访问控制怎么协同才靠谱
2.1 字段设计是类设计的第一步，也是最容易拍脑袋的一步
很多新手定义字段的时候，习惯"想到什么写什么"，甚至为了省事直接全部用public。这在一两个小类里问题不大，一旦类多了、协作的人多了，就是灾难。我先说字段类型选择上最常见的几个坑。
第一个坑是金额用double。做电商、支付、财务相关系统，金额计算用浮点数等于埋雷。0.1加0.2你以为是0.3，在double的世界里也可能是0.30000000000000004。这类精度问题在金额计算上绝对不能容忍，所以业务字段凡是涉及钱的，一律用BigDecimal。这个坑不是类设计特有的，但字段类型定义错了，整个类的根基就错了。
第二个坑是时间类型不统一。有的用long存毫秒，有的用String存"2024-12-18 10:00:00"，有的用java.util.Date，到了代码里到处是类型转换和格式转换，极其痛苦。建议一个项目里统一时间字段的存储类型，比如对外交互用long或Instant，数据库实体用LocalDateTime，避免在类之间传递的时候反复纠结。
字段的可见性设计也很关键。我的习惯是：默认全部private，只有子类需要访问的才考虑protected，只有常量或者真正的数据传输对象才用public。为什么这么保守？因为字段是类的内部状态，内部状态暴露得越多，类与外部的耦合就越深。你今天把某个字段从int改成long，如果它是public的，所有直接访问它的地方全都要改；如果它是private的，你只需改类内部的方法实现，对外部完全透明。
2.2 方法不只是行为，还是类的"对外承诺"
如果说字段定义了类"有什么"，方法就定义了类"能干什么"。方法设计的核心是职责单一。一个方法最好只做一件事。拿订单类举例，一个方法既要做数据校验、又要计算金额、还要更新数据库、还要发送通知，看起来省事，但这四个步骤里任何一个出问题，排查起来都极其痛苦。
方法签名设计同样有讲究。参数不要一长串——我见过有人写public void createOrder(String userId, String skuId, int count, BigDecimal price, String address, String phone, String receiverName, int addressType)，这种方法调用的时候很容易传错位置，而且语义模糊。合理的做法是把关联紧密的参数收敛成一个对象，比如把地址相关字段收敛成Address对象。判断一个方法签名好不好，有个很简单的标准：背下来能不能记住。超过四五个参数，基本就该重构了。
返回类型也要谨慎。有一个经典问题：方法查询不到数据时返回null还是抛异常？这没有绝对正确答案，但团队内部必须约定一致。我的选择是：读取单个对象时，如果查询不到，返回Optional或者null都行，但要明确写进文档；读取列表时，永远返回空集合而不是null。这一条约定能避免大量空指针问题。你想想，一个返回List的方法返回null，调用方循环之前全都得判空，稍不注意NPE就来了。返回空集合，这个烦恼直接消失。
2.3 访问控制修饰符的决策逻辑：不是语法问题，是架构问题
public、private、protected、默认（包级私有），这四个修饰符的选择，本质上是你在决定"谁能碰你类的内部"。很多新手搞不清楚protected和默认的区别，我换个方式给你解释。
private：只有类自己能访问。类的内部实现细节都放这里。这是封装的核心。 默认（什么都不写）：同一个包里的其他类可以访问。常用于包内部协作、不希望暴露给外部调用者的工具方法或内部常量。 protected：子类可以访问，同一个包的类也可以访问。常用于父类给子类预留的扩展点。 public：所有地方都能访问。这是类的对外接口，是承诺出去的东西，后续尽量保持稳定。
你注意一个模式：从private到public，可见性逐渐放大，同时你对代码变更的控制力逐渐减弱。我的经验是，一个类里public方法应该控制在少数几个核心操作上，其他统统收进private。比如前面那个Order类，对外暴露cancel和calculateDiscount就够了，校验状态是否可取消的helper方法完全可以是private。
访问控制还直接关系到测试成本。如果一个类的全部方法都是public，说明所有方法都是对外承诺，测试和重构时你要考虑的影响面会非常大。多藏一些private方法，把稳定的、核心的接口暴露为public，后续迭代压力会小很多。
3. new一个对象，JVM背后偷偷帮你做了哪些事
3.1 new关键字执行时，内存里发生了什么
很多人写Order order = new Order()写了几百遍，从没想过这一行代码背后有几个步骤。我建议你把它拆开理解，因为这是理解引用、对象、垃圾回收等一切概念的基础。
第一个步骤是类加载。如果Order类还没有被加载进JVM，JVM会通过类加载器去找到Order.class文件，把类的字节码加载进内存，在方法区（或者说元空间）生成Class对象。这个工作在第一次使用Order类时触发。后面我讲到静态变量时你会有更深体会。
第二个步骤是分配内存。JVM在堆上为这个Order对象划出一块内存区域。这块区域多大？由类的字段决定——orderId是一个引用，占4或8字节；createTime是long，占8字节；totalAmount是一个引用；status是一个引用。此外还有对象头等信息。这个计算不是让你去背，而是让你认识到：对象大小在类定义时就已经决定了，跟你给字段赋什么值无关。
第三个步骤是执行构造方法。内存分配完成后，JVM把对象的字段初始化为默认值（引用类型默认null，数值类型默认0，boolean默认false），然后调用构造方法执行你写的初始化逻辑。这个顺序很重要——你可以在构造方法里给字段赋值，但赋值之前，这个对象已经以"全默认值"的状态存在了。
第四个步骤是返回引用。注意，order变量里保存的并不是对象本身，而是对象在堆内存中的地址。我把这个引用传给别人的时候，别人拿到的是同一个地址，自然操作的就是同一个对象。
这几个步骤对应过来就理解了网上搜的"对象的创建"相关面试题常问的那个问题：一个对象创建过程中，类加载、内存分配、构造执行这几个步骤谁先谁后？答案很明确：类加载最先，内存分配其次，构造方法最后。构造方法不是创建对象的必要条件，JVM可以先分配内存再调构造方法，甚至在某些反序列化场景中，对象可以不通过构造方法创建出来。
3.2 构造方法的规则与容易踩的坑
构造方法有两条基础规则：方法名必须和类名完全一致，不能有返回值类型。如果写了返回值类型，编译器会把它当成普通方法处理，然后你就会遇到"我明明写了构造方法为什么字段没初始化"的问题。这个坑新手上当率很高。
另一条规则经常被忽略：如果你不写任何构造方法，编译器会生成一个无参构造方法；一旦你写了任何带参构造方法，默认无参构造方法就不会自动生成。也就是说：
public class Order { private String orderId; // 只写了带参构造 public Order(String orderId) { this.orderId = orderId; } }这时候如果你在外面new Order()，编译直接报错。很多框架（Spring、MyBatis、JSON反序列化）默认依赖无参构造方法，比如Spring通过反射创建bean、MyBatis从数据库查记录映射成对象，框架会去找无参构造方法。一旦你写了带参构造还不留无参构造，框架运行期就会抛异常。我的建议是：除非这个类明确不需要被框架管理，否则最好显式保留一个无参构造方法。
构造方法的修饰符也是热门问题，网上搜"java构造方法修饰符跟类一样吗"的人也很多。正确答案是：不需要完全一样。常见的私有构造方法就很有用。比如工具类（只有静态方法、不希望被实例化的类），你可以把构造方法声明为private，这样就杜绝了外部new出无意义的对象。单例模式的经典写法，也是利用private构造方法加上静态getInstance来控制的。
构造方法的重载有时候也会带来困扰。多个构造方法参数不同，职责不同，但新人在调用时容易调错。我建议控制构造方法数量，如果一个类的构造方法超过两三个，考虑用静态工厂方法或者Builder模式替代。举个实际例子：一个订单DTP可能要支持"从数据库读取的完整构造"和"用户下单时的新订单构造"两种创建场景，这时候写两个静态工厂方法fromDB(ResultSet rs)和createNew(userId, items)比写一堆构造方法清晰得多。
3.3 静态成员与实例成员：别把类变量当对象的便签贴
类里，字段和方法都有static和非static之分。static成员属于类本身，不static的属于每个对象实例。这个区别在内存和业务含义上都很重要。
static字段在整个JVM里只有一份，被所有实例共享。它适合存放全局配置、常量、计数统计之类的数据。比如在一个User类里定义public static final int MAX_AGE = 120，这个常量被任何地方用到都是同一个值，不存在每个对象一份的说法。
static方法类似，它不依赖具体实例状态，只依赖传入的参数和类静态字段。工具类的静态方法最常见，比如Math.max()、Collections.sort()。这里有个关键限制：static方法内部不能直接访问非static字段和非static方法，因为static方法运行时可能没有具体对象存在，你调一个实例字段根本不知道该取哪个对象的字段。反过来，实例方法可以访问static成员，因为类数据一定早于实例存在。
新手最容易犯的错误是：用static字段去存跟具体业务对象相关的数据。我见过有人在一个PurchaseService类里写public static String currentOrderId;，本意是"记录当前处理的订单"。结果并发一上来，所有线程共享这一个字段，A线程的订单号被B线程覆盖了，线上出了大事故。这种"共享变量保存个体状态"的用法，是static最典型的误用。静态字段应该用来保存那些真正的全局共享数据，而不是当作线程间的传话渠道。
4. 类与对象在内存中的真实面貌：栈、堆与方法区的分工
4.1 三个方面各管什么事
类与对象的内存布局，是理解Java运行时行为的关键。我尽量不堆术语，用城市功能类比来讲。
栈（虚拟机栈）：每个线程一个，存的是方法调用过程中的局部变量和中间结果。方法一旦执行结束，对应栈帧就会被弹出，局部变量随之销毁。所以局部变量的生命周期天然跟方法绑定，方法结束变量就该消失。这解释了为什么局部变量不初始化就能声明，但访问前必须赋值——因为栈帧里不会自动给你默认值。
堆：所有对象实际所在的地方。只要你new了对象，不管这个对象被谁引用，它都在堆里待着。堆是线程共享的，所以多线程访问同一个对象才需要加锁和同步，它们的对象都在同一片共享区域里。这块空间由垃圾回收器统一管理，你new完对象后不需要手动释放内存。
方法区/元空间：类的结构信息、静态变量、常量池在这里。比如Order类的Class对象、static字段值、方法字节码，都存放在这个区域。JDK 8之后改名为元空间，并且从JVM堆中移出到本地内存。
你可能已经发现，一个对象在内存里并不是"孤零零一个整体"在堆里的。它的引用在栈里，它的Class元信息在方法区里，它字段里那些引用类型的值又指向其他堆对象。画个内存图会特别直观，但先不展开，我重点讲几个会影响你日常写代码的内存认知。
4.2 引用传递的经典误区：你传的到底是值还是引用
这是Java新手翻车率最高的一个点。先记结论：Java方法参数传递永远是值传递，但这个"值"指的是：如果是基本类型，传的是基本类型的副本；如果是引用类型，传的是引用变量中保存的地址的副本。
什么意思？看这段代码：
public static void changeName(User user) { user.setName("老王"); user = new User("新用户"); }调用后，外部那个user对象的名称会被改成"老王"，但外部user还是指向原来的对象，不会指向new出来的"新用户"。因为user这个形参拿到的是原引用地址的副本，通过副本可以操作同一个对象（所以setName生效）；但把副本重新赋值给一个新对象，只改变了副本变量的指向，影响不到外部的原引用变量。
理解了这一点，"为什么我传一个对象进方法，改了属性外面也变了"和"为什么我在方法里给对象重新赋值，外面没有变化"这两个看似矛盾的现象就同时解开了。前者是因为改的是同一个对象的内容，后者是因为重新赋值只改了引用的副本。
这里有个实战建议：方法内部修改对象状态，想清楚这是不是方法本意的副作用。如果方法名是纯粹的查询或计算，却暗地里修改了传入对象的字段，这个设计很容易造成意想不到的bug。尤其是多人协作，A写的工具方法偷偷改了B传入的对象属性，B排查起来真的很痛苦。
4.3 对象的生命周期与垃圾回收：什么时机回收，什么时候需要你主动补充
对象在堆里产生，生命周期到"再也没有任何地方引用它"为止。垃圾回收器会周期性地扫描堆内存，把那些不可达的对象回收掉。这个设计解放了程序员，但也带来一个新的要求：如果你持有某个对象的引用不放，GC就认定这个对象还活着，它就永远不会被回收。这就是所谓的内存泄漏——不是泄漏到外面去了，而是该释放的内存一直占着。
实际业务中出现这种问题的场景很多：一个静态集合里存了所有处理过的订单对象，只增不减；一个监听器被注册后从没注销过；一个缓存map的key设计不合理，导致value永远无法被清理。每一条都会让堆内存持续增长，最后OOM。
那什么时候需要主动断开引用？我的经验是：短生命周期的对象不要被长生命周期的对象持有。比如一个请求级对象（RequestScope）被一个全局的单例对象持有，这个请求结束后对象本该被回收，但因为有全局引用在，它释放不了。遇到这种情况，要么重新设计谁持有谁，要么在合适的时机显式把引用置空，要么用WeakReference一类的弱引用机制。
但我也要提醒一句：别走极端，写代码时到处手动把变量置null，这是很多C背景程序员初写Java的毛病。Java的GC会处理大部分清理工作，置null通常是例外手段，不是常规操作。搞清楚对象的引用链条，比无脑置null更靠谱。
5. 类设计进阶：抽象、接口、内部类与Object类的那些约定
5.1 抽象类和接口，怎么选才不会选错
到了这个阶段，类不再是简单的数据载体，而要承担设计层面的角色。抽象类和接口是Java实现多态和模块解耦的两大利器，但很多人分不清什么时候用哪个。
抽象类是用abstract修饰的类，它不能被直接实例化，可以包含抽象方法（没有方法体），也可以包含具体方法、字段、构造方法。它的定位是：一族相近类的"半成品"模板。你可以在抽象类里把公共逻辑写好，把需要变化的步骤声明为抽象方法，让子类各自实现。比如一个Payment抽象类，里面有支付流程的公共逻辑（校验金额、记录日志），但具体的支付渠道对接（alipay、wechat、unionpay）留给子类实现。
接口（interface）从Java 8开始越来越强大，可以包含抽象方法、默认方法（default）、静态方法。它的定位是：能力契约。你定义了一个接口，就是定义了一套"必须具备的能力"，任何类实现了它，就承诺具备这些能力。支付场景里你可以定义一个Refundable接口，包含refund方法，凡是支持退款的支付渠道都实现它，而不支持的渠道可以不实现。
选抽象类还是接口，我给的判断标准很简单：如果你要表达的"是什么"（is-a）关系，且多个子类有大量公共代码要复用，用抽象类；如果你要表达的是"能做什么"（can-do）能力，且不同的类之间没有继承关系上的强制要求，用接口。实际项目中优先接口而非抽象类，因为Java是单继承，类继承了抽象类就不能再继承其他类，而接口可以多实现，设计的灵活度高很多。网上搜"抽象类和普通类的区别"关注度很高，其实抽象类和普通类的差别就两个：能不能被实例化、能不能有抽象方法。但真正有技术含量的，是抽象类和接口的边界判断。
5.2 内部类：什么场景值得用它
内部类就是把一个类定义在另一个类的内部，主要分为成员内部类、静态内部类、局部内部类和匿名内部类。不少新手觉得内部类语法复杂，干脆一律不用。但有些场景内部类非常方便。
成员内部类可以无条件访问外部类的所有成员（包括private的），适合表达"整体与部分"的强绑定关系。比如一个Order类里定义OrderItem内部类，订单和订单明细天然是整体与部分的关系，订单没了订单明细一般来说也就没有独立存在的意义。
静态内部类没有外部类实例的引用，不会隐式持有外部对象，更安全。构造复杂对象时，Builder模式经常用静态内部类。你在业务代码里可以看到大量User.builder().name("xxx").build()的写法，那个builder往往就是User类里的一个静态内部类。
匿名内部类（Java 8以后基本被lambda替换，但概念上仍然重要）用于快速实现一个只需要用一次的接口或抽象类。比如排序时Collections.sort(list, new Comparator<Product>() { ... })，后来变成list.sort((p1, p2) -> p1.getPrice().compareTo(p2.getPrice()))。lambda本质是对匿名内部类的一种简化包装。
我的建议不是要求你每种类都用内部类，而是当你遇到一个类的生命周期和功能完全依附于另一个类、单独抽出来反而别扭的场景，可以考虑内部类。它可以把"强相关"的代码聚在一起，减少类文件爆炸。但要小心成员内部类会隐式持有外部类引用，如果这个内部类被外部长生命周期对象持有，就会连带外部类对象也一直存活——又是一个内存泄漏的隐患。
5.3 为什么重写equals就必须重写hashCode
所有类都继承自Object类。Object类里定义了equals、hashCode、toString、getClass等基础方法。这些方法设计背后有一个对象协作的约定：如果两个对象通过equals方法判断相等，那么它们的hashCode必须相等。反过来不成立——hashCode相等不代表equals相等，两个不同的对象可能计算出相同的哈希值（哈希冲突）。
这个约定不是摆设，它是HashMap、HashSet等哈希容器的底层逻辑。HashMap在查找key的时候，先通过hashCode定位到某个桶，再用equals精确比较桶里的元素。假如你重写了equals但没有重写hashCode，两个业务上相等（比如orderId相同）的对象hashCode不同，HashMap就会把它们放进不同的桶里，导致你明明想查找的对象就是找不到。
实际操作中经常遇到一个场景：把数据库里查出来的订单对象放进HashSet去重，如果你只重写equals不重写hashCode，去重完全失效。所以我的规则是：当你在类里重写equals时，强制同步重写hashCode，并且equals中参与判断的字段，也要在hashCode计算中用到。另外toString方法建议重写，尤其是调试的时候，一个能打印出关键业务字段的toString，比默认的com.example.Order@1a2b3c4有用太多，能大幅缩短排查问题的时间。
6. 实战重构：把一段流水账代码改成优雅的类设计
6.1 先看一段典型的"哪里需要就写哪里"的代码
前面说了那么多基础概念，这一节用一个贴近真实业务的完整案例，把你学到的类设计知识串起来。假设我们现在要处理一个付款回调通知的逻辑，需求是：收到支付渠道的回调后，校验签名、更新订单状态、计算优惠金额、生成积分流水。很多刚学完类和对象的人，写出来的代码如下：
public class PayService { public void handleCallback(String orderId, String sign, String payChannel) { // 模拟查询数据库订单 String status = "PAID"; BigDecimal orderAmount = new BigDecimal("200.00"); boolean signOk = sign != null && sign.length() > 0; if (!signOk) { System.out.println("签名校验失败"); return; } if ("PAID".equals(status)) { BigDecimal discount = orderAmount.multiply(new BigDecimal("0.1")); BigDecimal finalAmount = orderAmount.subtract(discount); int points = finalAmount.intValue(); System.out.println("订单最终金额：" + finalAmount); System.out.println("赠送积分：" + points); // 更新数据库、写入流水…… } } }这段代码的问题非常典型：订单状态、金额、优惠规则、积分规则全部混在一个方法里；没有订单对象、没有支付渠道对象、没有流水对象；优惠和积分规则写死，完全没法扩展；而且所有逻辑都在打印和模拟，真正的更新、流水操作你也不知道该往哪里插。这个代码一旦业务有变化，比如优惠从固定折扣变成阶梯优惠、不同支付渠道优惠力度不同，你就只能不停地往方法里加if-else，直到代码彻底失控。
6.2 基于类设计思路的完整重构过程
重构的第一步不是动手写代码，而是识别业务概念。这段逻辑里有哪些核心概念？订单、支付渠道、支付结果、优惠策略、积分规则。每个概念各自承担什么职责？把它们变成独立的类，再让它们协作。
订单类负责自身状态和金额信息：
public class Order { private String orderId; private BigDecimal orderAmount; private String status; public Order(String orderId, BigDecimal orderAmount, String status) { this.orderId = orderId; this.orderAmount = orderAmount; this.status = status; } public void markPaid() { if (!"CREATED".equals(status)) { throw new IllegalStateException("当前状态不能标记为已支付: " + status); } this.status = "PAID"; } public String getStatus() { return status; } public BigDecimal getOrderAmount() { return orderAmount; } public String getOrderId() { return orderId; } }优惠策略抽成接口，方便后续实现不同的优惠算法：
public interface DiscountStrategy { BigDecimal calculateDiscount(Order order, String payChannel); } public class DefaultDiscountStrategy implements DiscountStrategy { @Override public BigDecimal calculateDiscount(Order order, String payChannel) { if ("VIP_PAY".equals(payChannel)) { return order.getOrderAmount().multiply(new BigDecimal("0.15")); } return order.getOrderAmount().multiply(new BigDecimal("0.1")); } }积分规则独立成类，而不是堆在回调方法里：
public class PointsCalculator { public int calculate(BigDecimal finalAmount) { return finalAmount.intValue(); } }最后，回调处理逻辑把这些类串联起来，自己只负责流程控制：
public class PayCallbackService { private final DiscountStrategy discountStrategy = new DefaultDiscountStrategy(); private final PointsCalculator pointsCalculator = new PointsCalculator(); public void handleCallback(String orderId, String sign, String payChannel) { if (!verifySign(sign)) { System.out.println("签名校验失败"); return; } Order order = queryOrderFromDB(orderId); order.markPaid(); BigDecimal discount = discountStrategy.calculateDiscount(order, payChannel); BigDecimal finalAmount = order.getOrderAmount().subtract(discount); int points = pointsCalculator.calculate(finalAmount); updateOrder(order, finalAmount); savePointsRecord(order, points); System.out.println("订单" + orderId + "处理完成，最终金额：" + finalAmount + "，积分：" + points); } }6.3 重构后的复盘：类的拆分到底带来了什么
对比两段代码，你可以很清晰看到类设计带来的四个变化。
第一，状态流转被约束。markPaid方法里控制了状态流转规则，外部不能随便把订单状态改来改去。这就是封装对业务规则的保护。如果后面需求变成"已发货订单不允许被标记为已支付"，你只需要改这一个方法，不用在整个项目里搜索所有跟状态赋值有关的代码。
第二，变化点被隔离。优惠策略从if-else变成了接口+实现类。明天新增一个节日优惠策略，你只需要新建一个FestivalDiscountStrategy类实现DiscountStrategy接口，然后在使用的地方替换一下即可。原来的回调方法一行都不用改，这符合开闭原则。
第三，每个类的可测试性大幅提升。DiscountStrategy可以单独写单元测试；PointsCalculator可以单独写单元测试；PayCallbackService可以用mock的Order和策略类来测流程。而原来那种一个方法里全干完的写法，测试时要把签名校验、订单查询、优惠计算全部串起来才能启动。
第四，阅读成本降低。回调方法里每一行都在做控制流的事——校验签名、查单、标支付、算优惠、算积分、更新、记录。每个步骤只用一行调用，而不是几十行细节。一个新人接手这段代码，从方法主干上就能看出整体流程，再深入每个类看细节。
这次重构我觉得也体现了类设计的终极目标：让你的代码结构匹配业务结构。订单这个业务概念，在代码里就应该有一个对应的Order类；优惠策略这个概念，在代码里就该有一个DiscoutStrategy接口。类不是语法要求，而是你把真实世界的复杂度映射到代码世界的桥梁。
以我多年的开发经验来看，类和对象从来不是背完定义就能掌握的。真正的提升发生在你写代码时开始思考"这个字段该不该暴露""这个方法应不应该放在这个类里""这个状态应该由谁管理"，这种思考习惯一旦养成，你的代码质量会有质变。如果这篇文章能帮你在类和对象的认识上前进一步，哪怕只解决了一个困扰许久的疑问，也算值了。
