大概两年前我接手过一套订单系统的维护任务。系统本身不算复杂线上却总出怪事隔几天就会出现一笔金额为负的订单记录个别订单的数量也被人改成个位数。排查到最后才发现不是推送接口写错了也不是数据库约束缺失而是订单实体类里 price、count、discount 这几个字段全被写成了 public。任何一端业务代码都可以随手来一句order.price -199编译器一声不吭日志里只能看到最终结果根本不知道是哪一行代码动的手脚。那次线上数据修完我对“封装”两个字算是彻底服气了。Java 面向对象有三大特性封装、继承、多态教程一般把封装放在第一个讲。但说句实话真正把封装当回事的开发者不算多。初学者容易觉得 private 就是把字段藏起来读代码反而更麻烦有些写了几年代码的人也习惯把实体类写成一堆 public 字段加一堆无脑 getter/setter还美其名曰“实体类本来就该这样”。这篇内容就围绕封装展开结合我自己踩过的坑聊一聊它到底在保护什么、从零开始怎么落地、哪些地方容易做过头以及最后沉淀下来的几条判断标准。适合刚接触面向对象的朋友也适合那些能写代码、但还没认真抠过设计细节的人。1. 先看一场没有封装的事故字段裸奔的代价1.1 一个字段被三十处代码直接操作之后把字段设计成 public表面上是图省事读写直接不用写一堆 getter/setter。但这种便利的代价等代码量上来之后才会慢慢显现。我当时看到的系统里order.price 和 order.count 在业务层、展示层、甚至定时任务里都被直接赋值赋值逻辑还互相打架有人按原价写有人按折扣后的价写还有人往里面塞了一个“占位价格”。线上出现的负数订单就是两个任务先改后读、读到一半又被另一个任务改掉造成的。这种问题最折磨人的地方在于它不会在编译期报错测试阶段也不容易被发现。public 字段给了所有代码同等的写权限谁都拦不住谁。等生产数据出了问题你只能把几十个引用点翻出来一个一个排除而真正写脏数据的那段代码可能早就在两三个版本之前被改掉了。说实话排查到后半夜的时候你对“面向对象”四个字的理解会比任何教程都深刻。1.2 更隐蔽的成本字段改名等于全局重构public 字段还有一个特别坑的地方只要字段名一变所有引用它的代码都得跟着变。有人会说“IDE 重命名一下就完了”但真正维护过老项目的人都懂跨模块、跨服务、甚至被字符串拼接和反射方式引用时自动重命名并不总是可靠。字段一旦被公开你就不再拥有随意调整内部表示的自由改个名字都可能引发连锁故障。封装最朴素的含义就是把字段这种“内部存储方式”藏起来对外只留方法出入口。字段哪怕改名字、改类型、甚至换成一堆 Map 来存外部调用都不受影响因为它们依赖的只是方法名称和参数。这一点很多教程一句话就带过了但在实际项目里它才是封装真正的红利。说到底封装不是让你把代码“写得复杂”而是让你在后续修改的时候少流点血。2. 封装到底在保护什么数据、自由度和契约2.1 自动售货机模型理解封装我个人最喜欢用自动售货机做类比。你站在售货机面前看到的是按钮、货品编号和出货口不需要知道机器内部弹簧怎么排列、马达怎么带动、纸币器怎么识别。售货机把内部细节全藏起来只给你几个操作入口这叫对外接口稳定。同时它又会检查你投的钱够不够、选的货还有没有库存这叫内部控制。Java 类的封装也是同一个道理。字段是内部存储方法是对外入口校验逻辑是内部控制。如果你把售货机的玻璃拆掉让所有人直接伸手去拿弹簧上的饮料表面上很自由但这种自由带来的必然是混乱有人多拿、有人碰坏机械结构、有人把东西塞回去。public 字段就是那块被拆掉的玻璃。2.2 编译期拦截和运行期校验是两道防线Java 的封装靠两个层面保证。第一层是编译期访问控制当你在类外面写下order.price -199时如果 price 是 private编译器会直接报错这段代码根本过不了编译。这一层能把低级问题挡在编码阶段比任何代码审查都高效。我见过很多实习生写的代码能跑起来但经常在奇怪的地方出脏数据多半就是缺了这一层约束。第二层是运行期业务校验。即使字段可以被写入我们也可以在 setter 或业务方法里检查数值是否合理比如价格必须大于 0、账号不能为空、余额不能为负。这两层配合相当于给内部数据加了两道防线。很多初学者只盯着第一层觉得“私有化”就是封装的全部其实第二层才是封装在真实业务里最大的价值——它把规则判断全部收拢到类内部外部无论怎么调用都必须先过这一关。2.3 封装为什么能降低改动带来的震荡没有封装的设计字段和逻辑散落在各处有了封装改动被控制在一个类里。我维护老项目时经常遇到这种需求把税率从 0.1 调整到 0.15。如果计价逻辑散布在十个类里那就要改十处漏一处就是事故。如果这套逻辑被封装在订单类的 getTotalAmount() 方法里外部只调用这一个方法那修改点就被限制在了一个方法内部。这其实就是“高内聚、低耦合”的体现。字段和行为放在同一个类里让相关逻辑尽量聚在一起外部通过方法访问减少模块之间的直接依赖。用大白话说封装是在给代码留出“内部随便折腾、外部纹丝不动”的空间。这个空间才是你后续重构和应对需求变化的底气。3. 落地第一套组合拳字段私有化、读写入口、校验逻辑3.1 第一步字段一律先加 private不要找任何理由实体类里的字段默认就应该是 private。哪怕你现在觉得这个字段不会有人乱动先写 private 也没有任何损失。需要暴露时再加方法也不迟。从 private 改成 public 很容易从 public 改回 private 却是伤筋动骨的大工程因为所有外部调用点都在期待现状。还有一点容易被忽略一个类内部如果多个方法都会修改同一个字段最好统一收口到一个方法里而不是每个方法各写各的赋值。我见过不少类字段确实是 private但类内部十个方法都有this.price xxx逻辑照样乱。私有化只是第一步收口才是关键。3.2 第二步按需提供 getter/setter而不是机械生成很多人用 IDE 一键生成所有字段的 getter/setter这其实是一种惰性。我平时做代码评审看到这种“全量生成”的类第一反应就是怀疑设计有问题。正确的做法是每个字段都问自己一遍外部真的需要读它吗真的需要改它吗如果不希望金额被外部修改那就不写 setter如果不想让订单号被外部看到连 getter 都可以不写。只读字段就是只有 getter 没有 setter这种类天然更安全状态在创建之后就不会被外部改动了。我做订单展示类时就常把核心业务字段设计成只读订单号、下单时间、原始单价都可以读但一律不允许外部修改要调价格必须走专门的方法过审批逻辑。3.3 第三步校验放进 setter 和构造器而不是放进调用方如果允许外部直接写order.price xxx那每个调用方都得先检查一遍价格人多手杂必漏。更合理的是只暴露一个 setPrice 方法在方法内部统一校验比如public void setPrice(double price) { if (price 0) { throw new IllegalArgumentException(价格必须大于0); } this.price price; }这样规则只写一次谁调用都一样。谁想再塞一个负价格进来得到的不是一条脏数据而是一个当场抛出的异常问题会立刻暴露。同样重要的是构造器校验。对象的属性最好在创建时就处于合法状态而不是等外部 new 完再一个个设置。如果构造器不校验那只要有人 new 了一个带负价格的对象后面 setter 也拦不住已经非法初始化的数据。我实际项目中习惯把构造器校验和 setter 校验抽成同一个私有方法比如 validatePrice让两处共用避免规则重复。再高级一点可以用静态工厂方法替代构造器比如Order.create(...)。工厂方法能表达更清晰的意图校验逻辑收在工厂内部。它还能在创建前先判断参数决定返回哪种子类型甚至返回 null 表示创建失败。对于复杂对象的创建这比 new 一把梭要好用得多。3.4 进阶getter 返回复制品避免内部引用直接暴露封装很容易踩的一条坑是字段如果是可变对象比如数组、List、Date 这类直接return this.list等于把内部引用交出去了。调用方拿到这个 List 之后可以随手 add、remove你的类内部数据会在你毫不知情的情况下被改掉而且你压根找不到是谁干的。对应的做法是防御性复制。getter 返回一个新副本public ListString getTags() { return new ArrayList(tags); }如果调用方真的需要修改让它修改返回的副本再通过专门的方法把修改落回内部。setter 一侧也一样别直接this.tags tags先new ArrayList(tags)存一份避免外部后续修改原 List 影响对象内部状态。这个细节在参数和返回值都涉及引用类型时特别重要很多人写了好几年代码还会在这里翻车。4. 访问权限修饰符选错级别等于白封装4.1 四种权限一张表说清Java 的访问控制级别有四档private、默认包级、protected、public。它们的可见范围差异一张表就能说清楚修饰符同类同包其他类不同包子类所有类private可访问不能不能不能默认不加可访问可访问不能不能protected可访问可访问可访问不能public可访问可访问可访问可访问有一个被反复误解的地方以为 protected 就是“子类可以访问”。完整语义其实是“同包 不同包子类”。也就是说两个类只要在同一个包下没有继承关系也能访问对方的 protected 成员而不同包的子类只能访问自己继承下来的那部分 protected 成员不能通过父类引用来访问。4.2 类成员的可见范围应该下探而不是上浮我见过不少项目字段一律 private 没问题但所有方法一律 public导致一个类对外露出十几个方法看似开放内部实现细节全暴露了。更稳妥的做法是先想清楚“谁需要用到这个方法”只有类内部用的辅助方法就设 private需要子类扩展重写可以设 protected只在同一个模块内配合使用用默认包级真正对外提供服务的方法才设 public。一个经验法则能 private 就不 protected能 protected 就不直接 public。权限每放宽一级就意味着有更多代码在依赖它。public 方法一旦被别人调用后续想改签名就得考虑兼容性这个代价在真实项目里往往很高。4.3 包级私有模块内部协作的好工具默认包级访问权限经常被忽略但它组织代码的时候非常好用。如果一个包就是你眼中的模块包内部几个类要互相配合那包级字段或方法可以让它们直接协作同时对外部包完全隐藏。比如某个内部工具类只需要被同一个包里的其他类使用方法就设成包级不写任何修饰符外部模块拿不到合作也方便边界也清晰。我自己设计功能模块时会刻意把实现类放在一个包里把对外接口放在另一个包里或直接定义成接口。实现类里的具体方法尽量用包级或 private只有接口方法才设 public。这样外部代码永远只依赖接口不依赖实现细节换实现的时候只动包内部调用方完全无感知。4.4 protected 别乱用它是“重开一扇窗”protected 在框架和模板方法模式里很有价值比如父类定义整体流程把某个步骤交给子类覆写那这个方法就需要 protected外部不可见、子类可改写。但也很容易被误用。不少初学者上来就把所有方法设成 protected觉得“以后可能被子类用到”结果类被继承后方法全可以被覆写父类反而难以维护自身的状态。原则很简单如果你没有预留扩展点的明确设计意图就不要用 protected。任何为“将来可能”加的权限都是在给现状添加不确定性。封装不是把所有门都锁上而是只开必要的门开多了和没锁没区别。5. 一个带业务行为的封装示例账户不该只是 getter/setter 集合5.1 反例余额可以被随意 set 的账户数据袋很多人写实体类习惯是 private 字段加 getter/setter业务逻辑全放外面。账户类于是被写成了这个样子balance 有 getter/setter外部使用时先 getBalance再判断余额够不够再 setBalance。这套流程在多个调用方反复复制逻辑一散就会出现有人忘记判断负数、有人比较符号写反。余额变负数或者多人并发操作时互相覆盖几乎是必然的事。这种设计的本质是把对象当成了纯数据容器让它丢失了自己的行为。Java 面向对象讲究的是“属性 方法”一体属性本应被方法管理而不是被外部代码搬来搬去。你如果只是想要一个字段袋子那不如直接用 MapString, Object何必费劲搞什么类。5.2 正例把行为封进类里让调用方无法绕过规则我一般会写成下面这个样子public class Account { private final String accountId; private double balance; public Account(String accountId, double initialBalance) { if (accountId null || accountId.trim().isEmpty()) { throw new IllegalArgumentException(账户ID不能为空); } if (initialBalance 0) { throw new IllegalArgumentException(初始余额不能为负数); } this.accountId accountId; this.balance initialBalance; } public String getAccountId() { return accountId; } public double getBalance() { return balance; } public void deposit(double amount) { if (amount 0) { throw new IllegalArgumentException(充值金额必须大于0); } this.balance amount; } public void withdraw(double amount) { if (amount 0) { throw new IllegalArgumentException(取款金额必须大于0); } if (amount this.balance) { throw new IllegalStateException(余额不足当前余额 this.balance); } this.balance - amount; } }和反例相比区别有几点。余额没有 setter外部改不动它只能通过 deposit 和 withdraw 两个业务方法来操作。取款规则也就是余额不足不能取被收进 withdraw 内部少检查一次都不可能。accountId 是 final创建之后不能再改账户、订单这类有业务标识意义的字段就应该这样固定下来。调用方写起来也会干净很多account.deposit(200); account.withdraw(50);它不需要关心 balance 怎么变化更不需要自己在外层做余额判断。两个线程同时调用 withdraw如果没做同步控制还是会有问题但那是另一个话题了。至少从职责上说余额的合法性已经由账户自己负责而不是散落在外部各处。5.3 再进一步不可变对象与静态工厂有些对象设计出来就不该变比如金额、日期区间、坐标这类值对象。把字段设成 final、不给任何 setter、getter 只返回基本类型或副本这就是不可变对象。不可变对象的好处非常多线程安全、可缓存、可放心共享不会因为被传递而遭到意外修改。创建不可变对象可以和静态工厂方法搭配代码如下public class Money { private final long cents; private Money(long cents) { this.cents cents; } public static Money ofYuan(double yuan) { if (Double.isNaN(yuan) || yuan 0) { throw new IllegalArgumentException(金额不合法); } return new Money(Math.round(yuan * 100)); } public long getCents() { return cents; } }构造器设成 private外部不能随便 new只能通过 ofYuan 创建所有校验都集中在工厂方法里。这样的封装不止保护内部数据连“怎么创建才合法”也一并保护了。做到这一步封装就不再只是语法层面的 private而是一种设计规则了。6. 过度封装也是坑什么时候该松一松6.1 症状一所有字段都配了 getter/setter类却没有任何方法如果一个类只有一堆私有字段和对它们的读写方法没有任何业务行为那它本质上是穿了 private 马甲的数据袋。外部一样可以通过 setter 随意改字段只是多套了一层壳。类的价值在于“状态和行为的一体化管理”而不只是“字段写成了私有”。我见过很多团队的代码规范要求每个字段都必须生成 getter/setter甚至用代码生成模板批量搞。结果就是一个订单类二十个字段、二十个 setter真正用到的可能只有三五个。剩下那些方法不但没人用还给未来留了无数扇门每一扇都会成为外部改动内部状态的口子。写类之前先想清楚哪些状态需要被外部修改哪些外部只需要读哪些连读都不需要。只给真正需要的门开门。6.2 症状二业务判断全堆在 Service 层对象变成哑巴另一种“过度封装”是把类写得特别干净字段私有、有 getter/setter但所有业务判断全放在 Service 层。Service 里写满了 if 判断余额、if 判断状态码对象自己反而对自身的规则一无所知。这种设计也就是常说的贫血模型。小项目里看着还行一旦业务复杂起来规则会在多个 Service 之间重复改一处漏三处几乎必然。正确的思路是反向思考先看这个规则跟哪个类的数据强相关就把它放回那个类。余额和取款规则天然属于 Account库存和扣减规则属于 Product这不需要纠结。只有那些涉及多个对象协作的流程才放到 Service 里去编排。6.3 症状三防御性拷贝用过头读数据也变得畏手畏脚防御性拷贝是好习惯但什么习惯都怕极端。如果一个类是纯内存临时对象生命周期极短外部传进来也不会缓存、不会再改那每次 setter 都 new 一个副本、getter 都再 new 一个副本就是纯浪费性能和内存。我自己的经验是先看对象会不会被外部持有足够长的时间。如果它只是方法之间传递的临时载体直接赋值就行如果它会进集合、进缓存、被多个线程共享再做防御性拷贝。很多人一听说“防拷贝”就无脑套结果系统内存占用翻倍查了半天定位不到原因这种经历我也有过。封装是为了安全但牺牲性能换来的安全得想想值不值。6.4 我的判断标准三个问题检验封装是否合理关于封装到底该做到什么程度我一般用三个问题来检验一个类。第一外部要完成这个对象的核心业务操作需要调用几个方法如果外部每次都要先 get、再判断、再 set那封装不合格应该让一个业务方法把整个步骤包住。第二不变量是否被收口比如余额不为负、税率在 0 到 1 之间、订单号不能为空这类规则必须集中在一个地方检查所有修改入口共用。如果存在任何一条修改路径能绕过校验那这个封装就是漏的。第三哪些东西本来就不该变业务标识、创建时间、计算结果能设计成 final 加只读的就不要留口子。能锁死的变化就不要给它敞开大门。用这三个问题过一遍很多设计问题会立刻现出原形。我做代码评审基本就是照着这三个问题来看的。最后说一点个人体会。封装这个主题看起来是语言基础但真正考验的是“边界感”——什么该藏、什么该露、什么允许变、什么不能变。我接手老项目时有个习惯先看一个类里字段和方法的分布如果字段能被外部随意改动、业务方法空心化、规则全散在 Service 里基本就能预料后续维护会踩哪些坑。反过来如果字段私有、入口收敛、规则内置哪怕它没写文档注释我也敢比较放心地接手修改。这种判断力不是背“封装就是 private”这种话就能得到的得靠一次次线上事故和重构慢慢练出来。希望这篇记录能帮你少走一点我走过的弯路。
大概两年前我接手过一套订单系统的维护任务。系统本身不算复杂线上却总出怪事隔几天就会出现一笔金额为负的订单记录个别订单的数量也被人改成个位数。排查到最后才发现不是推送接口写错了也不是数据库约束缺失而是订单实体类里 price、count、discount 这几个字段全被写成了 public。任何一端业务代码都可以随手来一句order.price -199编译器一声不吭日志里只能看到最终结果根本不知道是哪一行代码动的手脚。那次线上数据修完我对“封装”两个字算是彻底服气了。Java 面向对象有三大特性封装、继承、多态教程一般把封装放在第一个讲。但说句实话真正把封装当回事的开发者不算多。初学者容易觉得 private 就是把字段藏起来读代码反而更麻烦有些写了几年代码的人也习惯把实体类写成一堆 public 字段加一堆无脑 getter/setter还美其名曰“实体类本来就该这样”。这篇内容就围绕封装展开结合我自己踩过的坑聊一聊它到底在保护什么、从零开始怎么落地、哪些地方容易做过头以及最后沉淀下来的几条判断标准。适合刚接触面向对象的朋友也适合那些能写代码、但还没认真抠过设计细节的人。1. 先看一场没有封装的事故字段裸奔的代价1.1 一个字段被三十处代码直接操作之后把字段设计成 public表面上是图省事读写直接不用写一堆 getter/setter。但这种便利的代价等代码量上来之后才会慢慢显现。我当时看到的系统里order.price 和 order.count 在业务层、展示层、甚至定时任务里都被直接赋值赋值逻辑还互相打架有人按原价写有人按折扣后的价写还有人往里面塞了一个“占位价格”。线上出现的负数订单就是两个任务先改后读、读到一半又被另一个任务改掉造成的。这种问题最折磨人的地方在于它不会在编译期报错测试阶段也不容易被发现。public 字段给了所有代码同等的写权限谁都拦不住谁。等生产数据出了问题你只能把几十个引用点翻出来一个一个排除而真正写脏数据的那段代码可能早就在两三个版本之前被改掉了。说实话排查到后半夜的时候你对“面向对象”四个字的理解会比任何教程都深刻。1.2 更隐蔽的成本字段改名等于全局重构public 字段还有一个特别坑的地方只要字段名一变所有引用它的代码都得跟着变。有人会说“IDE 重命名一下就完了”但真正维护过老项目的人都懂跨模块、跨服务、甚至被字符串拼接和反射方式引用时自动重命名并不总是可靠。字段一旦被公开你就不再拥有随意调整内部表示的自由改个名字都可能引发连锁故障。封装最朴素的含义就是把字段这种“内部存储方式”藏起来对外只留方法出入口。字段哪怕改名字、改类型、甚至换成一堆 Map 来存外部调用都不受影响因为它们依赖的只是方法名称和参数。这一点很多教程一句话就带过了但在实际项目里它才是封装真正的红利。说到底封装不是让你把代码“写得复杂”而是让你在后续修改的时候少流点血。2. 封装到底在保护什么数据、自由度和契约2.1 自动售货机模型理解封装我个人最喜欢用自动售货机做类比。你站在售货机面前看到的是按钮、货品编号和出货口不需要知道机器内部弹簧怎么排列、马达怎么带动、纸币器怎么识别。售货机把内部细节全藏起来只给你几个操作入口这叫对外接口稳定。同时它又会检查你投的钱够不够、选的货还有没有库存这叫内部控制。Java 类的封装也是同一个道理。字段是内部存储方法是对外入口校验逻辑是内部控制。如果你把售货机的玻璃拆掉让所有人直接伸手去拿弹簧上的饮料表面上很自由但这种自由带来的必然是混乱有人多拿、有人碰坏机械结构、有人把东西塞回去。public 字段就是那块被拆掉的玻璃。2.2 编译期拦截和运行期校验是两道防线Java 的封装靠两个层面保证。第一层是编译期访问控制当你在类外面写下order.price -199时如果 price 是 private编译器会直接报错这段代码根本过不了编译。这一层能把低级问题挡在编码阶段比任何代码审查都高效。我见过很多实习生写的代码能跑起来但经常在奇怪的地方出脏数据多半就是缺了这一层约束。第二层是运行期业务校验。即使字段可以被写入我们也可以在 setter 或业务方法里检查数值是否合理比如价格必须大于 0、账号不能为空、余额不能为负。这两层配合相当于给内部数据加了两道防线。很多初学者只盯着第一层觉得“私有化”就是封装的全部其实第二层才是封装在真实业务里最大的价值——它把规则判断全部收拢到类内部外部无论怎么调用都必须先过这一关。2.3 封装为什么能降低改动带来的震荡没有封装的设计字段和逻辑散落在各处有了封装改动被控制在一个类里。我维护老项目时经常遇到这种需求把税率从 0.1 调整到 0.15。如果计价逻辑散布在十个类里那就要改十处漏一处就是事故。如果这套逻辑被封装在订单类的 getTotalAmount() 方法里外部只调用这一个方法那修改点就被限制在了一个方法内部。这其实就是“高内聚、低耦合”的体现。字段和行为放在同一个类里让相关逻辑尽量聚在一起外部通过方法访问减少模块之间的直接依赖。用大白话说封装是在给代码留出“内部随便折腾、外部纹丝不动”的空间。这个空间才是你后续重构和应对需求变化的底气。3. 落地第一套组合拳字段私有化、读写入口、校验逻辑3.1 第一步字段一律先加 private不要找任何理由实体类里的字段默认就应该是 private。哪怕你现在觉得这个字段不会有人乱动先写 private 也没有任何损失。需要暴露时再加方法也不迟。从 private 改成 public 很容易从 public 改回 private 却是伤筋动骨的大工程因为所有外部调用点都在期待现状。还有一点容易被忽略一个类内部如果多个方法都会修改同一个字段最好统一收口到一个方法里而不是每个方法各写各的赋值。我见过不少类字段确实是 private但类内部十个方法都有this.price xxx逻辑照样乱。私有化只是第一步收口才是关键。3.2 第二步按需提供 getter/setter而不是机械生成很多人用 IDE 一键生成所有字段的 getter/setter这其实是一种惰性。我平时做代码评审看到这种“全量生成”的类第一反应就是怀疑设计有问题。正确的做法是每个字段都问自己一遍外部真的需要读它吗真的需要改它吗如果不希望金额被外部修改那就不写 setter如果不想让订单号被外部看到连 getter 都可以不写。只读字段就是只有 getter 没有 setter这种类天然更安全状态在创建之后就不会被外部改动了。我做订单展示类时就常把核心业务字段设计成只读订单号、下单时间、原始单价都可以读但一律不允许外部修改要调价格必须走专门的方法过审批逻辑。3.3 第三步校验放进 setter 和构造器而不是放进调用方如果允许外部直接写order.price xxx那每个调用方都得先检查一遍价格人多手杂必漏。更合理的是只暴露一个 setPrice 方法在方法内部统一校验比如public void setPrice(double price) { if (price 0) { throw new IllegalArgumentException(价格必须大于0); } this.price price; }这样规则只写一次谁调用都一样。谁想再塞一个负价格进来得到的不是一条脏数据而是一个当场抛出的异常问题会立刻暴露。同样重要的是构造器校验。对象的属性最好在创建时就处于合法状态而不是等外部 new 完再一个个设置。如果构造器不校验那只要有人 new 了一个带负价格的对象后面 setter 也拦不住已经非法初始化的数据。我实际项目中习惯把构造器校验和 setter 校验抽成同一个私有方法比如 validatePrice让两处共用避免规则重复。再高级一点可以用静态工厂方法替代构造器比如Order.create(...)。工厂方法能表达更清晰的意图校验逻辑收在工厂内部。它还能在创建前先判断参数决定返回哪种子类型甚至返回 null 表示创建失败。对于复杂对象的创建这比 new 一把梭要好用得多。3.4 进阶getter 返回复制品避免内部引用直接暴露封装很容易踩的一条坑是字段如果是可变对象比如数组、List、Date 这类直接return this.list等于把内部引用交出去了。调用方拿到这个 List 之后可以随手 add、remove你的类内部数据会在你毫不知情的情况下被改掉而且你压根找不到是谁干的。对应的做法是防御性复制。getter 返回一个新副本public ListString getTags() { return new ArrayList(tags); }如果调用方真的需要修改让它修改返回的副本再通过专门的方法把修改落回内部。setter 一侧也一样别直接this.tags tags先new ArrayList(tags)存一份避免外部后续修改原 List 影响对象内部状态。这个细节在参数和返回值都涉及引用类型时特别重要很多人写了好几年代码还会在这里翻车。4. 访问权限修饰符选错级别等于白封装4.1 四种权限一张表说清Java 的访问控制级别有四档private、默认包级、protected、public。它们的可见范围差异一张表就能说清楚修饰符同类同包其他类不同包子类所有类private可访问不能不能不能默认不加可访问可访问不能不能protected可访问可访问可访问不能public可访问可访问可访问可访问有一个被反复误解的地方以为 protected 就是“子类可以访问”。完整语义其实是“同包 不同包子类”。也就是说两个类只要在同一个包下没有继承关系也能访问对方的 protected 成员而不同包的子类只能访问自己继承下来的那部分 protected 成员不能通过父类引用来访问。4.2 类成员的可见范围应该下探而不是上浮我见过不少项目字段一律 private 没问题但所有方法一律 public导致一个类对外露出十几个方法看似开放内部实现细节全暴露了。更稳妥的做法是先想清楚“谁需要用到这个方法”只有类内部用的辅助方法就设 private需要子类扩展重写可以设 protected只在同一个模块内配合使用用默认包级真正对外提供服务的方法才设 public。一个经验法则能 private 就不 protected能 protected 就不直接 public。权限每放宽一级就意味着有更多代码在依赖它。public 方法一旦被别人调用后续想改签名就得考虑兼容性这个代价在真实项目里往往很高。4.3 包级私有模块内部协作的好工具默认包级访问权限经常被忽略但它组织代码的时候非常好用。如果一个包就是你眼中的模块包内部几个类要互相配合那包级字段或方法可以让它们直接协作同时对外部包完全隐藏。比如某个内部工具类只需要被同一个包里的其他类使用方法就设成包级不写任何修饰符外部模块拿不到合作也方便边界也清晰。我自己设计功能模块时会刻意把实现类放在一个包里把对外接口放在另一个包里或直接定义成接口。实现类里的具体方法尽量用包级或 private只有接口方法才设 public。这样外部代码永远只依赖接口不依赖实现细节换实现的时候只动包内部调用方完全无感知。4.4 protected 别乱用它是“重开一扇窗”protected 在框架和模板方法模式里很有价值比如父类定义整体流程把某个步骤交给子类覆写那这个方法就需要 protected外部不可见、子类可改写。但也很容易被误用。不少初学者上来就把所有方法设成 protected觉得“以后可能被子类用到”结果类被继承后方法全可以被覆写父类反而难以维护自身的状态。原则很简单如果你没有预留扩展点的明确设计意图就不要用 protected。任何为“将来可能”加的权限都是在给现状添加不确定性。封装不是把所有门都锁上而是只开必要的门开多了和没锁没区别。5. 一个带业务行为的封装示例账户不该只是 getter/setter 集合5.1 反例余额可以被随意 set 的账户数据袋很多人写实体类习惯是 private 字段加 getter/setter业务逻辑全放外面。账户类于是被写成了这个样子balance 有 getter/setter外部使用时先 getBalance再判断余额够不够再 setBalance。这套流程在多个调用方反复复制逻辑一散就会出现有人忘记判断负数、有人比较符号写反。余额变负数或者多人并发操作时互相覆盖几乎是必然的事。这种设计的本质是把对象当成了纯数据容器让它丢失了自己的行为。Java 面向对象讲究的是“属性 方法”一体属性本应被方法管理而不是被外部代码搬来搬去。你如果只是想要一个字段袋子那不如直接用 MapString, Object何必费劲搞什么类。5.2 正例把行为封进类里让调用方无法绕过规则我一般会写成下面这个样子public class Account { private final String accountId; private double balance; public Account(String accountId, double initialBalance) { if (accountId null || accountId.trim().isEmpty()) { throw new IllegalArgumentException(账户ID不能为空); } if (initialBalance 0) { throw new IllegalArgumentException(初始余额不能为负数); } this.accountId accountId; this.balance initialBalance; } public String getAccountId() { return accountId; } public double getBalance() { return balance; } public void deposit(double amount) { if (amount 0) { throw new IllegalArgumentException(充值金额必须大于0); } this.balance amount; } public void withdraw(double amount) { if (amount 0) { throw new IllegalArgumentException(取款金额必须大于0); } if (amount this.balance) { throw new IllegalStateException(余额不足当前余额 this.balance); } this.balance - amount; } }和反例相比区别有几点。余额没有 setter外部改不动它只能通过 deposit 和 withdraw 两个业务方法来操作。取款规则也就是余额不足不能取被收进 withdraw 内部少检查一次都不可能。accountId 是 final创建之后不能再改账户、订单这类有业务标识意义的字段就应该这样固定下来。调用方写起来也会干净很多account.deposit(200); account.withdraw(50);它不需要关心 balance 怎么变化更不需要自己在外层做余额判断。两个线程同时调用 withdraw如果没做同步控制还是会有问题但那是另一个话题了。至少从职责上说余额的合法性已经由账户自己负责而不是散落在外部各处。5.3 再进一步不可变对象与静态工厂有些对象设计出来就不该变比如金额、日期区间、坐标这类值对象。把字段设成 final、不给任何 setter、getter 只返回基本类型或副本这就是不可变对象。不可变对象的好处非常多线程安全、可缓存、可放心共享不会因为被传递而遭到意外修改。创建不可变对象可以和静态工厂方法搭配代码如下public class Money { private final long cents; private Money(long cents) { this.cents cents; } public static Money ofYuan(double yuan) { if (Double.isNaN(yuan) || yuan 0) { throw new IllegalArgumentException(金额不合法); } return new Money(Math.round(yuan * 100)); } public long getCents() { return cents; } }构造器设成 private外部不能随便 new只能通过 ofYuan 创建所有校验都集中在工厂方法里。这样的封装不止保护内部数据连“怎么创建才合法”也一并保护了。做到这一步封装就不再只是语法层面的 private而是一种设计规则了。6. 过度封装也是坑什么时候该松一松6.1 症状一所有字段都配了 getter/setter类却没有任何方法如果一个类只有一堆私有字段和对它们的读写方法没有任何业务行为那它本质上是穿了 private 马甲的数据袋。外部一样可以通过 setter 随意改字段只是多套了一层壳。类的价值在于“状态和行为的一体化管理”而不只是“字段写成了私有”。我见过很多团队的代码规范要求每个字段都必须生成 getter/setter甚至用代码生成模板批量搞。结果就是一个订单类二十个字段、二十个 setter真正用到的可能只有三五个。剩下那些方法不但没人用还给未来留了无数扇门每一扇都会成为外部改动内部状态的口子。写类之前先想清楚哪些状态需要被外部修改哪些外部只需要读哪些连读都不需要。只给真正需要的门开门。6.2 症状二业务判断全堆在 Service 层对象变成哑巴另一种“过度封装”是把类写得特别干净字段私有、有 getter/setter但所有业务判断全放在 Service 层。Service 里写满了 if 判断余额、if 判断状态码对象自己反而对自身的规则一无所知。这种设计也就是常说的贫血模型。小项目里看着还行一旦业务复杂起来规则会在多个 Service 之间重复改一处漏三处几乎必然。正确的思路是反向思考先看这个规则跟哪个类的数据强相关就把它放回那个类。余额和取款规则天然属于 Account库存和扣减规则属于 Product这不需要纠结。只有那些涉及多个对象协作的流程才放到 Service 里去编排。6.3 症状三防御性拷贝用过头读数据也变得畏手畏脚防御性拷贝是好习惯但什么习惯都怕极端。如果一个类是纯内存临时对象生命周期极短外部传进来也不会缓存、不会再改那每次 setter 都 new 一个副本、getter 都再 new 一个副本就是纯浪费性能和内存。我自己的经验是先看对象会不会被外部持有足够长的时间。如果它只是方法之间传递的临时载体直接赋值就行如果它会进集合、进缓存、被多个线程共享再做防御性拷贝。很多人一听说“防拷贝”就无脑套结果系统内存占用翻倍查了半天定位不到原因这种经历我也有过。封装是为了安全但牺牲性能换来的安全得想想值不值。6.4 我的判断标准三个问题检验封装是否合理关于封装到底该做到什么程度我一般用三个问题来检验一个类。第一外部要完成这个对象的核心业务操作需要调用几个方法如果外部每次都要先 get、再判断、再 set那封装不合格应该让一个业务方法把整个步骤包住。第二不变量是否被收口比如余额不为负、税率在 0 到 1 之间、订单号不能为空这类规则必须集中在一个地方检查所有修改入口共用。如果存在任何一条修改路径能绕过校验那这个封装就是漏的。第三哪些东西本来就不该变业务标识、创建时间、计算结果能设计成 final 加只读的就不要留口子。能锁死的变化就不要给它敞开大门。用这三个问题过一遍很多设计问题会立刻现出原形。我做代码评审基本就是照着这三个问题来看的。最后说一点个人体会。封装这个主题看起来是语言基础但真正考验的是“边界感”——什么该藏、什么该露、什么允许变、什么不能变。我接手老项目时有个习惯先看一个类里字段和方法的分布如果字段能被外部随意改动、业务方法空心化、规则全散在 Service 里基本就能预料后续维护会踩哪些坑。反过来如果字段私有、入口收敛、规则内置哪怕它没写文档注释我也敢比较放心地接手修改。这种判断力不是背“封装就是 private”这种话就能得到的得靠一次次线上事故和重构慢慢练出来。希望这篇记录能帮你少走一点我走过的弯路。
