企业官网建设流程全解析

1. 从“会写类”到“懂对象”：类与对象到底在研究什么

“类与对象（中）”这个主题，卡在一个很微妙的位置。往前一步是基础语法，往后一步是设计模式，而中间这一步——构造、封装、访问控制、静态成员、对象关系——恰恰是很多自学程序员最容易“看懂了但写不好”的分水岭。我这些年看过的代码里，大量所谓“能用”的类，其实只是把数据装在结构体里的容器，并没有真正发挥面向对象的核心价值。

这个系列中篇要解决的，不是“类怎么定义”的问题，而是“类为什么要这样设计”的问题。比如构造函数为什么存在、封装到底在保护什么、静态成员和实例成员的根本区别是什么、两个对象之间的关系该用引用还是复制来表达。这些概念如果你在博客、视频教程里零散看过一些，但一直没串成一条线，这篇内容就是帮你把它们串起来用的。适合刚学会类的基础语法、想加深理解的同学，也适合工作一两年后发现自己的类经常改来改去、想搞清楚设计问题出在哪儿的开发者。

我在这篇里会尽量用“为什么”的视角来拆解每一个机制，配合可直接跑通的代码示例和踩坑记录，把中篇该覆盖的核心细节一次讲透。先说第一块：对象到底是怎么被创建出来的，构造函数在其中扮演了什么角色。

2. 构造函数与对象创建：一切对象问题的起点

2.1 构造函数不只是“初始化”那么简单

很多初学者对构造函数的理解是“在创建对象时给字段赋初值的方法”。这个理解不算错，但太窄了。构造函数真正在做的事情，是把一个“合法的空壳对象”完整地变成“可安全使用的实例”。用生活里的例子来类比：买一辆车，你拿到钥匙的那一刻，车子不能只是一堆零件堆在地板上，它必须是加好了油、调好了座椅、验过了刹车才能交到你手上。构造函数就是那个“出厂质检流程”，保证对象一出生就处于一个合理、完整、可用的状态。

这个区别直接影响代码质量。我在评审代码时经常见到这样的写法：

public class Order { public String orderId; public double amount; public boolean paid; public Order() {} // 空构造 }

这个空构造看起来人畜无害，但它留下了一个巨大的隐患：使用者可以创建一个Order对象，然后不给orderId、不设amount，甚至忘了把paid置为true，对象就以一个“半死不活”的状态流转到业务逻辑里。等到后面某个方法读取orderId时才发现是空字符串，排查半天。

正确的做法是，用构造函数把“创建对象时必须满足的条件”写死：

public class Order { private String orderId; private double amount; private boolean paid; public Order(String orderId, double amount) { if (orderId == null || orderId.isBlank()) { throw new IllegalArgumentException("订单号不能为空"); } if (amount < 0) { throw new IllegalArgumentException("金额不能为负数"); } this.orderId = orderId; this.amount = amount; this.paid = false; // 新订单默认未支付 } }

这样一改，Order类从“能创建”变成了“只能按正确方式创建”。调用者想拿到一个Order实例，就必须提供合法的订单号和金额。这个约束不是文档里写的“请记得填字段”，而是由编译器强制执行的——你没法跳过构造函数。这就是构造函数第一个被低估的作用：它在语言层面帮我们做“不变量维护”（invariant maintenance）。

2.2 初始化顺序：一个容易踩但文档很少提的细节

构造函数执行的时候，不是只有构造函数体在跑。一次完整的对象创建，包含了好几个阶段，顺序一旦搞错，排查起来十分隐蔽。

以Java为例，完整顺序是这样：

1. 分配内存空间。
2. 执行父类的构造函数（从最顶层父类开始向下）。
3. 按声明顺序初始化本类中的字段默认值（字段初始化器/成员变量赋值）。
4. 执行构造函数体内剩余的代码。

也就是说，如果你写了这样的代码：

public class Config { private String name = loadName(); // 第一次读配置 public Config() { this.name = loadName(); // 构造函数里又读了一次 } private String loadName() { // 读配置文件，返回字符串 } }

loadName()会被调用两次。这在某些场景下不是bug，但如果loadName()有副作用（比如远程调用、累加计数、写日志），就会出现奇怪的重复执行。我见过一个真实案例：某推送服务的配置类里，字段初始化器会向追踪系统上报一次启动事件，构造函数里又主动调用了一次初始化方法，结果每次服务启动就上报两条记录，监控面板上的启动次数直接翻倍。

正确的设计很简单：字段初始化器和构造函数体之间不要做重复的事情。要么全部用字段初始化器，要么全部在构造函数里统一初始化，不要把同一种初始化逻辑拆在两处。

提示：如果你习惯用依赖注入框架（比如Spring），还要注意字段初始化器运行的时机可能早于依赖注入完成。也就是说，在字段初始化器里调用一个依赖属性，可能会拿到 null。这种问题比普通初始化顺序更隐蔽，我通常建议：不要在字段初始化器里做任何依赖外部状态的操作。

2.3 构造重载、链式构造与Builder模式的选择

构造重载本身不难，难的是重载多了之后怎么办。我见过某个订单类有六个构造函数，参数从(String, double)到(String, double, String, String, int, boolean)一应俱全。调用方拿到这个类，根本分不清该用哪个，填错参数类型也不是不可能。

实际上，当构造参数超过四五个、而且其中很多是可选项时，就该考虑用Builder模式或静态工厂方法了。Builder模式的本质，是把“构造对象”从一个巨大的构造函数调用，拆成了一系列可读性极强、每一步都带语义的赋值操作：

Order order = Order.builder() .orderId("A1001") .amount(299.0) .customerName("张三") .remark("加急") .build();

这个写法在可读性和可维护性上完胜六个重载构造函数。同时要养成的习惯是：构造函数重载之间应该互相委托（链式调用），而不是各自复制一份初始化逻辑。比如：

public Order(String orderId, double amount) { this(orderId, amount, false); } public Order(String orderId, double amount, boolean urgent) { // 真正的初始化逻辑只在这里写一份 }

这样后续加字段，只需要改最完整的那个构造函数，其他重载自然跟着生效。这不是语法技巧，是降低维护成本的工程习惯。我们项目中，凡是超过三个参数的类型，一律优先考虑Builder或静态工厂方法，这个约定在代码评审阶段就会把关。

2.4 对象初始化时机的“黄金三问”

写构造函数之前，我建议自己先问三个问题。这三个问题能过滤掉大部分“看似能用、实则隐患”的初始化设计。

第一问：这个对象创建之后，哪些字段是“必须已经有值的”？这些字段必须出现在构造函数参数里，不给就无法创建。第二问：哪些字段可以有默认值？这些字段放在字段声明处或构造函数体内给默认值，而不是让调用方每次传入。第三问：哪些字段是“创建之后允许改变”的？允许改变的话，提供 setter；不允许改变的话，考虑设置成 final 或只读属性。

我见过很多初始化混乱的类，本质上都是这三个问题的答案没想清楚。想清楚之后，构造函数该有什么参数、该留什么默认值、该暴露什么修改入口，都会变得非常明确。这比背诵“构造函数的作用”有用得多，因为它直接把设计决策落到了代码结构上。

3. 封装与访问控制：Java/C#/Python背后的共同逻辑

3.1 封装保护的到底是什么

说起封装，教科书里最爱讲的一句话是“把数据隐藏起来，通过方法访问”。但这句话隐含了一个问题：数据为什么非要“隐藏”？如果只是怕被别人看见，private 的意义就太弱了。

封装真正保护的是“类的内部一致性”。还是拿订单举例。假设paid字段是 public 的，业务代码里就可以随手写order.paid = true来标记付款。表面上没什么问题，但如果你要求“支付必须同时记录支付时间、生成支付流水号、触发回调通知”，那直接赋值paid就绕过了一整套业务规则。最后的结果是：订单状态为已支付，但支付时间字段是 null、流水号缺失、通知没发。数据不一致的问题就这么来的。

封装要做的事情，是把“类的状态变化”收束到受控的方法入口里。比如：

public class Order { private boolean paid; private LocalDateTime paidAt; private String paymentSerial; public void markPaid(String serialNo) { if (this.paid) { throw new IllegalStateException("订单已支付，不能重复支付"); } this.paid = true; this.paidAt = LocalDateTime.now(); this.paymentSerial = serialNo; // 可以在这里触发支付完成后的业务回调 } }

调用方想改变支付状态，就只有一个入口markPaid()，而这个方法会把所有配套的状态一起更新。即使将来业务规则变了，比如“支付前必须校验订单未过期”，你也只需要改这一个方法。这就是封装的核心回报：状态变更集中管理，业务规则变更只改一处。

3.2 四种访问修饰符：选型背后的设计逻辑

很多语言都有 public、protected、private 这类访问控制。选型的关键不是“能选哪个”，而是“这个成员到底给谁用”。我一般用这套标准来判断：

• private：只给本类自己用。这些是实现细节，外部压根不需要知道。字段优先 private，这是默认选项。
• protected：给本类和子类用。当你在设计一个基类、明确知道子类需要访问或重写某些行为时使用。
• public：对本类和所有外部调用方开放。这是对外契约，一旦公开就很难收回，所以要格外小心。
• 包级私有（default/package-private）：给同一个包内的协作类用。这个级别的存在感很低，但非常实用——比如同一模块内部需要共享某些能力，但又不希望暴露给包外使用者时，就可以用它。

选型时最大的坑不是选错级别，而是默认给了 public。很多同学写代码图省事，所有字段和方法一律 public。短期看是方便了，但三个月后，你根本分不清哪些成员是类的对外契约、哪些只是内部实现。别人调用你这个类的时候，面对一堆 public 方法也一头雾水。

我在实际项目中其实有一个很朴素的口诀：能 private 就 private，只有在确实需要暴露时才提升访问级别。不要为了“以后可能用到”而提前公开，以后真用到的时候，再放开也不迟。

注意：语言之间的访问控制细节有差异。比如 Python 的“_单下划线”只是约定，不会真正阻止外部访问；Java 的 protected 还牵扯跨包的继承访问规则。但设计思想是通用的——访问修饰符表达的是“设计意图”，而不是“安全机制”。外部真要想绕过，总是有办法的，关键在于你明确的意图能引导使用者走上规范路径。

3.3 getter/setter 不是“字段代理”，而是行为入口

一个典型误区是：类里写了 private 字段，然后配上一对毫无逻辑的 getter/setter，这种代码等于把封装做成了表面功夫：

public class User { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } }

这跟直接 public 字段几乎没区别。真正的 getter/setter 应该承担两件事：读取时保护数据、写入时校验状态。比如年龄字段，setter 里可以校验取值范围：

public void setAge(int age) { if (age < 0 || age > 150) { throw new IllegalArgumentException("年龄必须在0到150之间"); } this.age = age; }

再比如“身份证号”这种字段，一旦设置就不允许修改，那么应该不提供 setter，只提供 getter 和构造函数赋值。有些同学看到这可能会说：“不是有 Bean Validation 注解吗？为什么还要手动校验？” 注解校验和 setter 校验并不冲突——注解负责声明式校验，setter 负责兜底保护，尤其是那些没有走标准校验框架的赋值路径，靠 setter 这层才能堵住。

所以，一个合格的设计者在写 getter/setter 时，想的不是“我要暴露这个字段”，而是“这个字段的读写规则是什么”。规则简单到确实不需要任何逻辑时，直接用 IDE 生成的 getter/setter 没问题；规则复杂时，就该把 setter 换成带业务含义的方法（比如markPaid()，而不是setPaid(true)）。

3.4 不可变对象：封装做到极致后的红利

当你把所有字段都设为 private、去掉了 setter、只在构造函数里完成初始化，你就得到了一个不可变对象。不可变对象有几个实用红利：线程安全天然具备（没有状态变更，自然不会有竞态条件）；可以作为哈希表的键而不用担心哈希值变化；可以作为配置对象缓存起来重复使用。

Java 里经典的String就是不可变对象。你拼接字符串得到的永远是新对象，旧对象不受影响。设计一个不可变类，需要做到这几点：所有字段 private 且 final；不提供任何修改字段的方法；类本身尽量 final（防止子类破坏不可变）；如果字段里有可变对象，拷贝后再保存或返回副本。

我在实际工作中偏向于：配置项、值对象（Value Object）、数据快照，优先设计成不可变。“可变”留给那些确实需要频繁状态流转的实体类（比如订单状态机）。这个习惯养成了，类的设计复杂度会下降很多，因为不可变对象从根本上减少了一类排查难度极高的bug——状态被某个地方意外修改导致的连锁反应。

4. 属性、字段与计算成员：语言差异背后的统一思想

4.1 为什么很多语言要单独提供“属性（Property）”

Java 里我们写了那么多 getter/setter，C# 则是直接在语言层面支持属性：

public class Person { public string Name { get; set; } }

Python 则用@property装饰器实现类似能力。这些设计看似只是语法糖，背后其实藏着一个统一思想：访问一个成员看起来像个字段，但它的行为可以是一个方法。调用方不需要关心person.Name背后是真字段还是动态计算的——这种“访问方式统一”的好处是，你可以随时把实现从普通字段换成带逻辑的计算属性，而调用方代码一字不改。

Java 没有原生属性，所以从 Java 转 C# 或者 Python 时，会觉得它们比 Java “少写了很多样板代码”。但反过来，Java 用户也要理解：属性不是用来“省代码”的，它依然是封装的一部分——当你把Name { get; set; }改成Name { get { return _name.ToUpper(); } }时，依然是在用属性做行为封装。

4.2 计算属性的适用场景

计算属性（Computed Property）是一个很讨巧的设计：不存值，而是根据其他字段临时计算。比如订单的“总金额”如果由“单价 × 数量”得出，就没必要单独存一份总额字段，直接在 getter 里算即可：

public class OrderItem { private double unitPrice; private int quantity; public double getTotalAmount() { return unitPrice * quantity; } }

这种做法的好处是：永远不会出现总额和单价不一致的情况，因为总额本来就是派生的。一旦你存了一个“总额”字段，就必须在单价或数量变化时同步更新它，而“忘记同步”恰恰是这类bug的最高发源头。

我的判断标准是：如果某个值能从已有数据稳定推导出来，就不要缓存它。只有推导过程开销极大、且被频繁读取时，才考虑缓存（此时用懒加载 + 失效标记）。

4.3 字段、属性、方法的取舍速查

很多刚从教程里学完“类与对象”的同学，对什么时候用字段、什么时候用属性/方法，还是比较随缘。这里分享一个供大家参考的放下表：

使用这张表时，目标不是“严格分类”，而是让你在写每一行成员时都有意识地想一想：这个成员真的需要暴露吗？它是数据、派生值、还是行为？一旦想清楚，类的结构自然就清晰了。这也是“类与对象（中）”这块内容最有价值的部分——从语法上升到设计取舍。

5. 静态成员与实例成员：一个“共享”还是“独有”的问题

5.1 static 的本质是“类型级别”，不是“对象级别”

很多新手把 static 理解成“全局变量”或“工具方法”，这没有抓住本质。准确说，static 成员属于类本身，在所有实例之间共享；实例成员属于每个对象，各自独立。

一个很好的判断标准是：这个数据是该类型所有实例共用的信息，还是每个实例自己的状态？比如“订单状态”是实例级的，每笔订单不同；而“订单状态的枚举合法性”“订单编号生成规则”是类型级的，所有订单共用一套逻辑，就应该用 static。

但 static 的使用也容易踩坑，最大的坑是：static 字段天然是全局状态。很多人写了一个带 static 字段的类，本意只是共享一个配置，结果因为任何地方都能随意改写这个字段，导致程序行为在不同时机下不一样，最难排查的那类“幽灵bug”就这么来的。

5.2 静态方法、工具类与公共状态

如果方法不依赖实例字段，不访问实例状态，就可以设计为静态方法。把这类方法集中起来的类叫工具类（Utility Class）。工具类本身没什么问题，但用得太多会掩盖设计上的缺失——比如把本该属于某个类的业务逻辑拆到工具类里，反而破坏了内聚性。我更推荐的方式是：先把方法写在它最相关的类里，只有确实与状态无关、且确实多处复用时才抽成工具方法。

另一点要注意的是静态单例。比如private static final Singleton INSTANCE = new Singleton();，这种写法确实可以保证全局只有一个实例，但代价是：你失去了对创建时机和生命周期的控制。测试时想换一个 mock 实例也困难。对于配置中心、连接池这类确实全局唯一的资源，单例是合理的；对于平时写的业务类，尽量不要动辄单例。

5.3 静态成员初始化的顺序陷阱

静态代码块、静态字段初始化器、静态方法之间的执行顺序，也是一个经典藏雷点。JVM 加载类时会先执行静态字段初始化器和静态代码块（按代码顺序），而且只执行一次。示例：

public class AppConfig { private static AppConfig instance = new AppConfig(); private static String version = "v1.0"; public AppConfig() { System.out.println(version); // 这里会输出 null！ } }

问题在于：instance的初始化早于version的初始化，导致构造函数运行时version还是 null。这种问题在“看起来顺序正常”的代码里很难一眼发现。处理建议很简单：不要把静态字段的初始化依赖关系搞成交叉引用，静态字段之间最好按依赖顺序声明，或者干脆把这些初始化挪到显式方法里调用。

5.4 实例成员的“生命周期”与内存布局

对象创建之后，不是“永远活在内存里”的。现代语言一般都有垃圾回收机制，但开发者仍然需要理解对象何时可以被回收。判断标准其实一句话：这个对象还被引用着吗？一旦没有任何引用指向它，它就成了可回收对象。

我在项目里见过的一个经典内存问题：某服务用一个静态列表缓存所有登录用户的 Session 对象，但没有清理过期会话。时间一长，列表中堆积了大量已经没有引用的用户对象——不，准确说，列表本身维持着引用，所以这些对象永远“活”着，造成内存持续上涨。这种问题的本质是：静态容器误把本该短期存在的对象，生命周期无限延长了。

所以使用 static 集合做缓存时，一定要同时想好“释放策略”。否则“共享”就变成了“泄漏”。

6. 对象之间的关系：关联、聚合与组合的实践分级

6.1 三种关系的本质区别

“类与对象（中）”到这里，就进入了更偏设计的一层：对象与对象之间到底以什么方式产生联系。教科书上常讲三种关系：关联（A认识B）、聚合（A包含B，但B可以独立存在）、组合（A拥有B，B的生命周期随A而终结）。单看定义容易懵，用业务例子拆开就清楚多了：

• 关联：一个用户“使用”一台打印机。两台打印机被多个用户共享，用户注销了打印机还在。
• 聚合：一个班级“包含”若干学生。班级解散了，学生依然存在，可以转到其他班级。
• 组合：一个订单“拥有”订单行。订单删除时，订单行也应该一起删除——订单行离开订单没有独立业务意义。

用代码表达时，关联和聚合通常都是持有引用（字段指向另一个对象），区别在于生命周期是否由自己管理；组合则往往在构造函数中创建被包含对象，并随主对象一起销毁。

我见过的一项实践经验是：拿不准用哪种关系时，先问“如果A没了，B还应该存在吗？”如果B失去独立价值，用组合；如果B有自己独立的生命周期，用聚合。这个判断比死记硬背定义有用得多。

6.2 到处都是 getXXX() 调用的“火车事故”

对象关系设计失败的典型症状是“火车事故代码”——一段很长的调用链，比如：

order.getCustomer().getAddress().getCity().getZipCode()

这种写法看起来很流畅，但实际上把调用方和整条调用链上的所有类都耦合在了一起。任何一环发生变化，这行代码就要跟着改。更麻烦的是，它很容易造成空指针——链上任何一环返回 null，直接爆炸。

更合理的做法一定是通过外层类提供语义化方法，把链条藏起来。比如：

// 在 Order 类中定义 public String getCustomerCity() { return customer != null ? customer.getCity() : ""; }

这样调用方只依赖 Order 一个类，就不用满世界找链条关系了。这也是类设计时“高内聚、低耦合”的具体落地：让类主动把自己能力提供出来，而不是把自己的内部关系暴露给所有人看。

6.3 深拷贝、浅拷贝与引用传递：关系设计的隐形坑

对象关系设计中，绕不开“复制”的话题。直接赋值B = A，实际上 B 和 A 指向同一个对象——修改 B 的属性，A 也会同步变。这在有些场景下是期望行为，但很多 bug 恰恰源于“以为复制了，其实只是复制了引用”。

举个最常见的场景：登录用户信息被复制到多个页面组件对象里复用，某处代码不小心改了其中一个组件的用户姓名，结果所有地方的用户名都变了。要避免这个问题，要么统一设计为不可变对象，要么提供真正的深拷贝方法（复制对象及其内部引用对象）。

我常用的判断标准是：如果这个对象是“配置”“元数据”“值类型”，优先不可变 + 共享引用；如果这个对象是“可变实体”，传给外部时要考虑是否给对方“写权限”。不给写权限的方法，就是返回一个只读视图或拷贝。

7. 常见问题与排查技巧实录：类与对象设计的避坑清单

7.1 空指针和默认值相关的三大魔幻现场

大凡写过一阵子面向对象代码的人，都见过下面这三种问题。这不是某一种语言独有的，而是“类与对象”设计时没有把空值策略想清楚导致的。

第一个是“对象存在但内部没初始化”。比如构造函数漏了一个字段，或者字段初始化顺序有问题，对象创建成功但内部状态不完整。排查方法很简单：在构造函数里完成所有必填字段的赋值，然后写一个if (字段 == null) throw ...的防御校验兜底。

第二个是“getter 返回 null 导致调用方空指针”。这通常意味着调用方根本不希望拿到 null，但设计者没有保证。修复方式：对于值类型字段，可以返回默认值（比如空字符串、空集合）而不是 null；对于真正的“可能不存在”的关联对象，用 Optional 或者显式的判空方法。

第三个是“集合字段初始化为 null 而不是空集合”。很多人写private List<String> tags;而不初始化，在有参构造里也没赋默认值，于是调用方执行tags.add(...)时直接 NPE。治本方法是：字段声明处就初始化成空集合，或者在构造函数里赋值一个空集合。宁可多花一点内存，也不要让空引用成为常态。

7.2 隐式依赖与脆弱基类问题

类设计里还有一种隐蔽问题：两个看似不相干的类，因为隐藏在字段里的隐式依赖而耦合在一起。例如，某个配置类内部依赖System.getenv("APP_ENV")，另一个业务类读这个配置类得到的结果，在不同环境下表现不同，但代码里完全看不出环境参数在哪里传入的。这种隐式依赖最麻烦的地方是测试复杂——你没法轻易 mock 环境变量。

我给出的改进方向是：把外部依赖显式注入，或者通过构造函数参数明确传递。比如new AppConfig(env)而不是在构造函数里偷偷读环境变量。这个习惯养成后，代码的测试性会有肉眼可见的提升。这也是对象设计层面“依赖倒置”思想的一个简单落地——别让类自己去捞全局变量，让使用方把需要的东西递给它。

7.3 对象 equals 与 hashCode 的一个经典血案

排序、去重、集合查找时，对象如果不重写equals和hashCode，结果会完全不符合直觉。默认实现比较的是“引用是否相同”，而业务上我们通常希望比较“内容是否相同”。

我曾经调试过一个奇怪问题：同一个订单金额，A集合里能查到，B集合里查不到。后来定位到原因是 A 集合用了对象引用作为键，而业务代码创建了两个内容相同但引用不同的对象。解决办法是：对值对象重写equals和hashCode，并且保证参与equals的字段不可变——否则把对象放进 HashSet 后，再修改它的字段，HashSet 就找不到它了。这也是我们之前提到不可变对象的另一层价值。

7.4 内部类与匿名类带来的“不可见耦合”

还有一种容易忽略的类关系问题来自内部类（Inner Class）。比如 Java 里为了 UI 事件回调写了一个匿名内部类，它隐式持有了外部类的引用。如果这个匿名内部类被某个静态集合长期持有，那么外部类对象也会被连带持有，永远无法被回收——这就是“内存泄漏”的一个常见来源。

排查这类问题的一个技巧：写代码前先想一下这个内部类实例的生命周期会不会超过外部类实例。如果会，把内部类改写成静态内部类，或者在合适时机移除引用。这个坑在 GUI 编程和异步回调中尤其常见。

7.5 调试类设计问题的三个实用锦囊

定位类设计问题，和定位纯算法问题的思路不太一样。前者往往不是某个逻辑算错了，而是对象状态、关系、生命周期出了偏差。这里分享我常用的三个排查方向：

第一个是“打印对象图”。当不确定两个对象是不是同一个引用时，把各自的 hashCode 或内存地址打出来看一眼。这个方法土，但极有效，一秒就能确认“修改为何会互相影响”。

第二个是“缩小变化范围”。类设计问题经常在多个对象交互中暴露。把业务代码注释掉一大半，只保留创建和读取两个动作，看问题是否还在。如果不在，再逐渐把操作加回来，二分定位到具体是哪一次状态变更引入了问题。

第三个是“把可变对象改成不可变对象试试”。如果一个类的字段不断被各处修改、状态越来越乱，干脆给它冻结（去掉 setter、设为 final），然后用“创建新对象”代替“修改老对象”。你可能会惊讶地发现，很多逻辑瞬间变简单了。

顺带说一句：我十分推荐在团队代码评审中重视 private 字段的可变性设计。建议把“哪些字段可变、哪些不可变、对象生命周期由谁管理”作为评审清单的一栏。这比评审“代码风格是否统一”更能拦住设计层面的隐患。

7.6 快速自查：类与对象设计常见反模式

我结合这些年代码评审的实际经验，整理了一份“类与对象中篇学完后的自检表”，每一条都可以对照自己的代码走一遍：

每次写完一个新类，对照这张表检查一遍，基本能过滤掉七八成常见的低级问题。剩下的“设计合不合理”属于经验问题，要靠长期看代码、写代码、被代码坑来积累。

提到“被代码坑”，多说一句实战观察：越是经验丰富的开发者，越不会急着定义属性、写 getter/setter。他们往往先写这个类的使用场景（调用方代码），再回头决定需要哪些构造参数、哪些私有字段、哪些公共方法。这个方法我特别推荐给大家——类设计不是从字段开始，而是从使用场景开始。你把调用方代码写出来，一眼就能看出这个类缺什么方法、哪些方法根本不需要暴露。这一招，对我自己写代码的质量提升非常明显。

“类与对象（中）”这块内容，本身就处在“语法入门”和“设计进阶”的中间地带。理解了构造、封装、静态成员、对象关系和生命周期管理，你写出来的类就会从“一堆字段的容器”变成“有行为、有边界的业务模型”。这也是面向对象编程真正开始发挥威力的位置。