1. 包不只是给代码“分文件夹”那么简单1.1 为什么非要有包很多人在刚接触Java时都会觉得package这行代码就是个摆设——反正写在文件最顶上不写也能编译过写了也看不出有什么明显作用。这种想法在你写练习代码的时候确实没什么大问题可一旦代码量上去了或者开始跟别人协作没有包这层东西场面会非常难看。最简单的例子你和同事各写了一个类都叫Utils。没有包这两个类放在同一个项目里直接撞名编译器立刻报错谁来用、怎么用全是问题。有了包以后com.xxx.common.Utils和com.xxx.order.Utils虽然类名都叫Utils但只要加上全限定名就能同时存在、互相不干扰。所以包最本质的作用是解决命名空间隔离的问题而不是单纯的目录整理。其次是组织与安全边界。包可以看作一套代码的“部门划分”——不同部门之间只开放必要的信息内部实现细节可以吃自己的饭、关自己的门。这一点要和后面的访问权限连起来理解单独一个包没多大意思包配合上权限修饰符才能真正形成代码结构的保护壁垒。还有一点容易被忽略JVM看待类的完整身份本来就是“包名类名”这个全限定名。java.lang.String如果只叫String那跟其他地方的String就没法区分了。所以包名不是给程序员的便利贴而是类在运行时真正的一部分“身份证信息”。1.2 包名与目录的映射理解编译器的机械逻辑从物理结构上看包名和目录是一一对应的。package com.a.b;这个类文件必须放在com/a/b这个目录里否则编译期直接报错。这个规则很死板但是理解起来很简单编译器根据包名去定位源文件JVM根据包名去定位类文件路径就是包名把点号换成斜杠。这个映射关系带来一个常见问题很多新手一开始会把类随手丢在src根目录然后写package的时候随便编了个名字。编译一次就会报“类文件不在对应目录中”之类的错误。解决方法也很直接——按照包结构重新建目录把文件放进去。IDE通常能帮你自动整理但如果你在用命令行编译就得自己留意这是绕不开的基础操作。包名本身的命名一般遵循域名倒置规则比如你的项目挂在某个域名下就用域名反写作为前缀后面接项目名、模块名。这个规则的核心目的就是给包名加一个“全世界相对不会撞车”的前缀。个人项目里虽然没必要搞那么严格但从一开始养成这个习惯以后发布公共库或用别人的库时能省很多心。1.3 import 的作用被很多人理解偏了我见过不少新手对import有一种误解以为它像C/C里的#include一样把某个类的代码“粘贴”到了自己文件里。其实在Java里import只是让编译器知道“我下面代码里写的Utils到底指哪个全限定名”它不会把文件内容合并进来纯粹是省去你每次写全限定名的麻烦。举个例子import com.xxx.common.Utils; public class Demo { public static void main(String[] args) { Utils u new Utils(); } }等价于public class Demo { public static void main(String[] args) { com.xxx.common.Utils u new com.xxx.common.Utils(); } }区别只是后者手累一点。理解了这个底层机制之后很多奇怪问题就有解了比如你和同事的类都叫Utils你同时需要它们时import两个同名类是不行的这时候解决办法就是其中一个不导入直接用全限定名写出来编译器照样了解你在说什么。我建议业务代码里尽量写明确的单类型导入少用import xxx.*这种通配导入。通配导入虽然省字但一旦不同包里有两个同名的类编译器会优先匹配更具体的那个代码一多就变成“看名字猜不出来源”的局面排查起来很头疼。1.4 静态导入用得好调代码用不好调空气import static是Java里比较容易被遗忘的语法它的作用是把某个类的静态方法和静态字段“导入”到当前文件里让你调用的时候不用写类名。典型场景是写测试时断言方法一堆assertEquals如果全带上类名前缀代码会长到没法看。静态导入之后import static org.junit.jupiter.api.Assertions.assertEquals; assertEquals(3, result.size());看着清爽很多。但这个东西真不能滥用。如果导入了大量静态方法你代码里的某个方法调用到底是本类定义的还是继承来的还是静态导入来的阅读者得一个一个溯源代码的“可推理性”会变得很差。我的个人准则是同一个类的静态成员导入的个数别超过三五个而且仅限于语义非常明确的方法比如常量类里的枚举值、测试断言工具。2. 四个访问修饰符公私有别之外还有两个容易被低估的家伙2.1 一张表看透可见范围Java里的访问权限修饰符一共有四个public、protected、默认也叫包私有、private。很多教程用一句话概括“public全都能用private只有自己能看。”这句话没毛病但只答对了一半。真正的边界是下面这张表修饰符同一个类内同一个包内不同包的子类全局public可以可以可以可以protected可以可以可以不行默认包私有可以可以不行不行private可以不行不行不行注意一个容易记混的点protected能“跨包访问”的前提是你访问的这个对象是子类实例而且是在子类内部通过继承关系去访问。不是说你在任何地方拿一个父类引用就能访问它的protected成员。这个细节坑过不少人我放到下面单独说。2.2 protected 的“拧巴”属性protected是四个权限里最微妙的一个。它允许同包的类访问也允许不同包的子类访问但不同包的子类访问时有一条硬规矩要访问的是继承过来的那个成员本身得通过子类类型的引用来操作。看下面的场景package a; public class Parent { protected int money 100; }package b; import a.Parent; public class Child extends Parent { public void ok() { money 50; // 可以子类内部直接访问继承来的成员 } }但是package b; import a.Parent; public class Other { public void demo() { Parent p new Parent(); // p.money 30; // 编译不过不同包里不能拿父类引用直接访问protected成员 Child c new Child(); // c.money 30; // 编译不过同样是不同包不能通过子类实例访问继承的protected成员 } }为什么最后一行也不行因为在Java的规则里protected在跨包场景下只保护“子类自己内部”的访问视角——子类在自己肚子里能用这个继承来的成员但子类对外不负责“销售”这个成员。说得再直白一点权限是给继承者本人的“内部权限”不是给继承者去代理给别人用的。这个规则看起来绕其实是有道理的。否则protected就等于“只要我愿意继承这个类我就能把这个成员泄露给全世界”那它跟public就没什么区别了。理解了这一层你在设计继承体系的时候就会更谨慎到底要不要放protected放了之后别人继承你的类会有什么连锁影响。2.3 包私有的隐蔽价值访问权限设计中最被低估的其实是默认权限——也就是什么都不写、不加任何修饰符的情况。很多新手以为“不写就是没有权限控制”实际上它是实实在在的包私有只有本包内部能访问。我在实际项目中经常利用包私有来做一种设计把某个模块的“内部零件”只开放给同一包下的其他类。比如一个解析器对外只有一个Parser类是public的剩下的TokenDecider、SyntaxSplitter这些辅助类全部做成包私有甚至它们的构造器也放着不写public。这样从外面看整个解析器只有一个入口内部怎么折腾都行改动辅助类完全不影响调用方重构自由度高很多。这种做法在框架设计里特别常见。你去翻一些开源库的源码会发现真正public的类只占少数大量工具类、内部实现类都是默认权限。对比起来如果一开始图省事全写成public后期这个类一旦被外部代码依赖想缩权限就只能破坏性升级很难受。2.4 权限的“最小暴露原则”不是怕泄密是怕牵一发动全身很多人在争论“字段到底要不要全部privategetter/setter”。我要说private不是银行的保险柜它防的不是恶意攻击者而是防止别人在本不该依赖的地方产生依赖。假设你要改一个类的内部缓存策略原来用HashMap后来发现并发场景不合适得换成ConcurrentHashMap。如果这个字段是public的凡是直接访问过这个字段的调用方全得跟着改如果它是private的你只需要保证外部方法的语义不变内部实现随便换。所以“private”保护的并不是数据本身而是你将来修改代码的自由——这是封装最有价值的地方。给一个我自己常用的判断标准方法只是模块内部协作用的能放包私有就不要public字段几乎一律private需要拿出来看时给getter需要被人改时给setter并想想“是不是有更好的命令式方法”protected只在明确设计继承扩展点时使用不要因为“以后可能有人继承”就提前滥用。访问权限其实是一个“代码沟通协议”它告诉后来者哪些东西你可以安心踩着走哪些只是路过不要碰。协议越清晰代码的长期可维护性越高。3. 方法重载同名方法的“多面人生”3.1 到底什么叫重载编译器怎么认方法重载Overload的定义一句话就能说清**同一个类里方法名相同参数列表不同各方法之间彼此独立。**参数列表不同可以是参数个数不同可以是参数类型不同也可以是参数顺序不同——只要能让编译器区分出来就算重载。注意重载跟返回类型没有关系。你不能写两个方法一个int foo()一个String foo()参数完全相同试图用返回类型来区分。编译器一看签名方法名参数类型列表都一样直接判定重复定义。原因也简单方法签名是编译器判断“你到底调哪一个”的依据而返回类型在调用时经常被忽略比如foo(); // 返回值没用到你让编译器怎么猜根本没法猜。所以记住第一条铁律方法签名里不包含返回类型返回类型不同永远不能构成重载。再看重载的典型场景。同样一个createUser方法参数不同行为略有差异public User createUser(String name) { return createUser(name, null); } public User createUser(String name, String nickname) { return createUser(name, nickname, null); } public User createUser(String name, String nickname, int age) { // 真正执行创建逻辑 }这段代码最大的好处是调用方只需要记住一个方法名按自己拿得到的信息选参数最少的版本内部再统一收敛到最终实现。这也是一种“API连贯性”设计对外接口保持同一个动词不同场景用参数作区分。3.2 自动装箱把重载变成了“视力测试”Java的基本类型和包装类型会自动转换这在重载场景下会引出很微妙的坑。最常见的就是null参数的“薛定谔选择”问题。public class OverloadDemo { public void show(int a) { System.out.println(int: a); } public void show(Integer a) { System.out.println(Integer: a); } public static void main(String[] args) { // show(null); // 编译错误ambiguous, 类型不明确 } }为什么show(null)直接报歧义因为null既可以被当成int的自动装箱目标也可以被当成Integer的引用类型参数编译器在两个候选之间完全没有优先级可依据干脆拒绝编译。这个错误在IDE里非常常见你写的时候觉得“应该会选包装类型吧”真实情况是Java压根不给你这个“应该”。再往深一层基本类型之间的自动升级也会参与重载选择。假设有这两个方法public void print(short s) { ... } public void print(int i) { ... }调用print(1)时因为字面量1默认就是int所以会精确匹配print(int)不会去找print(short)。如果是print((short) 1)才会匹配到print(short)。重载的选择规则是“精确匹配优先找不到精确匹配再考虑扩展”比如public void print(long l) { ... } // 调用 print(1)1 是 int没有 print(int) 时才会自动升到 long这个过程叫基本类型拓宽转换也是重载匹配规则的一部分。平时写代码很少用到这么细的层次但一旦出现莫名其妙的编译选择就要怀疑是不是自动装箱和类型拓宽在捣乱。3.3 可变参数重载世界里最容易被绕晕的玩法可变参数int... args在重载里是最容易出歧义的语法糖。它的本质是一个数组参数但调用时可以像列表一样传任意多个值也可以完全空着。public class VarargsDemo { public void test(int... nums) { System.out.println(varargs); } public void test(int n) { System.out.println(single); } public static void main(String[] args) { test(10); // 输出 single精确匹配优先于可变参数 // test(); // 编译错误无法区分是调用空的可变参数还是别的 } }test(10)为什么输出single因为Java的匹配规则里固定参数的方法优先于可变参数方法。换句话说人能一眼看出来“哦你是想传一个数”编译器也一样它会优先选不需要把参数包成数组的那个。但test()就麻烦了可变参数版本允许空参数假如方法集里没有其他零参数同名方法编译器是能接受的会当可变参数为空数组来处理可如果同时存在一个test()编译器同样会困惑。所以在设计可变参数重载时记得留点空白给编译器也留点清醒给自己可变参数方法的多个重载版本很容易出现公共调用集测试时一定要把边界值考虑进去。3.4 重载的“语义一致性”才是设计灵魂从语言层面来说重载的门槛很低——参数不同加上方法名相同就算。但从工程层面说重载不是让你随便起一堆同名方法的通行证。同一个方法名被重载的每一组参数都应该在语义上能归到同一个概念。save()保存数据、save(String name)保存并给数据命名、save(String name, boolean overwrite)保存时是否覆盖——这些都在“保存”这个动作的合理范围内。但如果一个方法叫calc一个版本算利润另一个版本却去更新数据库那就属于重载的滥用。调用方只知道名字一样很容易在错误的地方调出意外的行为这种代码本质上是一种“安全陷阱”。我见过一些老代码同一个方法重载了七八个版本参数从int到String到Object到接口实现逻辑还各种分叉维护起来非常痛苦。重载的正确姿势更接近“收敛”而不是“发散”多个版本最终应该统一汇聚到同一个核心实现上这样核心逻辑只改一处其他重载版本只是个参数适配的壳。4. 重载和重写双胞胎容易认错的两个地方4.1 一个看编译期一个看运行期落脚点完全不同方法重写Override发生在子类和父类之间子类重新定义了父类的某个方法方法名、参数列表、返回类型或返回类型的子类型都保持一致访问权限不能比父类更严。这里最容易出事的区分点是重载是同一个类里“多一个方法”重写是父子类之间“替换一个方法的实现”。你可以在子类里同时看到三种情况class Parent { public void work() { System.out.println(parent work); } public void work(String name) { System.out.println(parent work: name); } } class Child extends Parent { Override public void work() { System.out.println(child work); } public void work(int times) { // 这是重载子类新增了参数为 int 的 work } }上面这段代码里child.work()调用的是子类覆写后的版本child.work(xxx)调用的仍然是父类的版本child.work(3)则是子类自己新增的重载方法。这三条调用路径混在一起新手经常分不清哪个是哪个。好用的判断口诀是**方法签名变了就是重载方法签名一模一样只是换了实现体就是重写。**跟你是谁没关系跟在哪里写的也没关系只看签名。4.2 Override 这个“逃犯识别器”一定要用有没有Override注解运行效果一模一样。也就是说即使你不写这个注解正确的重写也能正常执行。那它的价值在哪Override是一个编译期检查器——它会强制编译器去确认“这个方法确实是重写了父类或接口的某个方法”。如果你原本想重写却不小心把参数类型写错了方法就变成了重载编译器不会报错程序跑起来自然也不会调用你写的这个“伪重写”方法。但加了Override之后编译器直接提示“没有找到要重写的方法”你当场就能抓住这个低级错误。这个坑我真实踩过。曾经想覆写某个方法手滑把参数从Object写成了String编译顺利通过运行时却一直走父类逻辑排查了好久才发现方法根本没重写成功。从那以后我的习惯是只要子类里出现一个跟父类同名方法的意图一律先写Override让编译器替我把关。4.3 多态下的动态绑定调用哪个方法编译器说了不算方法重载与重写交叉在一起时会出现经典的“动态绑定”问题。class Animal { public void speak() { System.out.println(animal speak); } } class Dog extends Animal { Override public void speak() { System.out.println(dog bark); } } public class Demo { public static void main(String[] args) { Animal a new Dog(); a.speak(); // 输出 dog bark运行时看的是实际对象类型 call(a); // 输出动物在叫 call(new Dog()); // 输出狗狗叫 } public static void call(Animal x) { x.speak(); } public static void call(Dog x) { System.out.println(狗狗叫); } }第一处a.speak()变量声明类型是Animal但实际对象是Dog方法执行时JVM根据对象真实类型找到Dog.speak所以输出“dog bark”这就是重写的动态绑定。第二处和第三处更有意思call(new Dog())时编译器会根据参数类型选择call(Dog)这个重载版本走的是编译期静态绑定跟运行时对象真实类型没半毛钱关系。可一旦进入call(Animal x)方法体内部x.speak()又走动态绑定回到Dog的实现。这种“重载看编译期声明类型、重写看运行期实际类型”的混合规则是很多多态相关拦截问题的根源。理解它你才算真正把这章学透了。5. 工程实战里可以少踩的坑5.1 包结构设计先于写代码听起来像废话但真没几个人做到新手写项目经常是类写完了一堆文件夹乱七八糟最后看目录自己都皱眉头。包结构的核心原则是**“依赖方向清晰”**业务模块包不能反过来依赖工具包里的接口去实现自己的核心逻辑核心领域包更不该去依赖那些只在内部分层使用的解析包。举一个我见过的失败案例某项目把所有的工具类一股脑丢在util包结果util包不到半年膨胀到一百多个类好几个类还反向依赖业务模块的类导致每次想重构任何一个业务模块都牵连着一堆工具类。正确做法是按功能域分包订单相关的放order支付相关的放payment每个功能域内部再分出api、service、dao、model等子包。这样模块边界清楚包与包之间的依赖图才不会变成一团乱麻。还有一点容易忽略包之间的访问权限配合。两个分层包之间对外暴露的类用public、对外暴露的方法用public其他一律收紧。如果有一天你要换掉底层实现改动范围能控制得很小就是因为外面的包根本没有能力触达内部的“零件”。5.2 重载的数量不是越多越好命名才是最便宜的沟通成本我自己的重载设计原则是“先少后多按需重载”。一开始只提供最常用的参数版本等到真实调用方有明确需求时再补新版本不要一次性把所有可能参数组合全铺开。原因很现实每多一个重载版本阅读者就多看一条分支如果五个版本里有三个根本没被调用那就是纯噪声。比较稳妥的做法是把核心实现封装成一个带完整参数的方法其他重载版本都往这个方法汇聚public User createUser(String name) { return createUser(name, 0, null); } public User createUser(String name, int age) { return createUser(name, age, null); } private User createUser(String name, int age, String remark) { // 真正逻辑在这里其他重载调用它 }这样真正复杂的方法被控制成private或包私有对外只有简洁的“半成品壳”未来要加参数只在中间层新增一个重载并统一转向完整的私有方法即可。整条链路好维护也不容易漏改逻辑。5.3 权限与“以后可能会用到”为什么会成为技术债的温床“权限放得宽一点吧以后可能会用到”——这句话几乎在每个项目评审里都能听到也是我眼里最典型的技术债脚本。权限一旦放开调用方就可能产生依赖依赖一旦形成你后来的每一步重构都得考虑兼容成本。所谓“以后可能用到”往往根本没发生等你真要用的时候你直接加一个public方法都比无脑放大既有权限更可控。根据我的经验最能减少争议的办法是让访问权限成为设计方案的一部分而不是写完代码后的补丁。设计类的时候先把“外部要用的接口”列出来这些方法设成public类与类之间的协作方法设成包私有字段一律private。然后再按包分层把不同包的“合作契约”明确下来。这个过程只需要动笔几分钟收益却贯穿整个项目生命周期尤其是别人接你的代码时部署边界一眼就能看出来。5.4 说到最后重载使用体验上还有几个“直觉反例”重载再常见也有一些反直觉的边角值得写代码时心里挂个号null值调用重载方法大概率触发歧义编译错误遇到时别硬猜显式强转一下类型比如foo((String) null)。可变参数的数组展开在重载里会触发“先精确后可变”的规则如果你想强制走可变参数版本就显式传一个数组。泛型类型擦除会让两个看似不同的重载“撞车”比如print(ListString)和print(ListInteger)在编译时会变成同一个签名直接编译失败必须在命名上区隔开。重载方法里使用基本类型和包装类型混搭时记得测空值空指针永远比编译错误难查得多。最后分享一点个人感受包、访问权限、方法重载这三件事单独拉出来每一个都不难难的是把它们串起来想问题了。包决定代码模块的边界权限决定模块之间信息的可见度重载决定了同一个入口的包容度。设计一个类甚至一个系统的时候这三样东西其实是同一件事的三个视角——你在构建一个“对外清晰、对内自由、变化可控”的结构。写小练习的时候多纠结几回真正做项目的时候就能少折腾几轮。
1. 包不只是给代码“分文件夹”那么简单1.1 为什么非要有包很多人在刚接触Java时都会觉得package这行代码就是个摆设——反正写在文件最顶上不写也能编译过写了也看不出有什么明显作用。这种想法在你写练习代码的时候确实没什么大问题可一旦代码量上去了或者开始跟别人协作没有包这层东西场面会非常难看。最简单的例子你和同事各写了一个类都叫Utils。没有包这两个类放在同一个项目里直接撞名编译器立刻报错谁来用、怎么用全是问题。有了包以后com.xxx.common.Utils和com.xxx.order.Utils虽然类名都叫Utils但只要加上全限定名就能同时存在、互相不干扰。所以包最本质的作用是解决命名空间隔离的问题而不是单纯的目录整理。其次是组织与安全边界。包可以看作一套代码的“部门划分”——不同部门之间只开放必要的信息内部实现细节可以吃自己的饭、关自己的门。这一点要和后面的访问权限连起来理解单独一个包没多大意思包配合上权限修饰符才能真正形成代码结构的保护壁垒。还有一点容易被忽略JVM看待类的完整身份本来就是“包名类名”这个全限定名。java.lang.String如果只叫String那跟其他地方的String就没法区分了。所以包名不是给程序员的便利贴而是类在运行时真正的一部分“身份证信息”。1.2 包名与目录的映射理解编译器的机械逻辑从物理结构上看包名和目录是一一对应的。package com.a.b;这个类文件必须放在com/a/b这个目录里否则编译期直接报错。这个规则很死板但是理解起来很简单编译器根据包名去定位源文件JVM根据包名去定位类文件路径就是包名把点号换成斜杠。这个映射关系带来一个常见问题很多新手一开始会把类随手丢在src根目录然后写package的时候随便编了个名字。编译一次就会报“类文件不在对应目录中”之类的错误。解决方法也很直接——按照包结构重新建目录把文件放进去。IDE通常能帮你自动整理但如果你在用命令行编译就得自己留意这是绕不开的基础操作。包名本身的命名一般遵循域名倒置规则比如你的项目挂在某个域名下就用域名反写作为前缀后面接项目名、模块名。这个规则的核心目的就是给包名加一个“全世界相对不会撞车”的前缀。个人项目里虽然没必要搞那么严格但从一开始养成这个习惯以后发布公共库或用别人的库时能省很多心。1.3 import 的作用被很多人理解偏了我见过不少新手对import有一种误解以为它像C/C里的#include一样把某个类的代码“粘贴”到了自己文件里。其实在Java里import只是让编译器知道“我下面代码里写的Utils到底指哪个全限定名”它不会把文件内容合并进来纯粹是省去你每次写全限定名的麻烦。举个例子import com.xxx.common.Utils; public class Demo { public static void main(String[] args) { Utils u new Utils(); } }等价于public class Demo { public static void main(String[] args) { com.xxx.common.Utils u new com.xxx.common.Utils(); } }区别只是后者手累一点。理解了这个底层机制之后很多奇怪问题就有解了比如你和同事的类都叫Utils你同时需要它们时import两个同名类是不行的这时候解决办法就是其中一个不导入直接用全限定名写出来编译器照样了解你在说什么。我建议业务代码里尽量写明确的单类型导入少用import xxx.*这种通配导入。通配导入虽然省字但一旦不同包里有两个同名的类编译器会优先匹配更具体的那个代码一多就变成“看名字猜不出来源”的局面排查起来很头疼。1.4 静态导入用得好调代码用不好调空气import static是Java里比较容易被遗忘的语法它的作用是把某个类的静态方法和静态字段“导入”到当前文件里让你调用的时候不用写类名。典型场景是写测试时断言方法一堆assertEquals如果全带上类名前缀代码会长到没法看。静态导入之后import static org.junit.jupiter.api.Assertions.assertEquals; assertEquals(3, result.size());看着清爽很多。但这个东西真不能滥用。如果导入了大量静态方法你代码里的某个方法调用到底是本类定义的还是继承来的还是静态导入来的阅读者得一个一个溯源代码的“可推理性”会变得很差。我的个人准则是同一个类的静态成员导入的个数别超过三五个而且仅限于语义非常明确的方法比如常量类里的枚举值、测试断言工具。2. 四个访问修饰符公私有别之外还有两个容易被低估的家伙2.1 一张表看透可见范围Java里的访问权限修饰符一共有四个public、protected、默认也叫包私有、private。很多教程用一句话概括“public全都能用private只有自己能看。”这句话没毛病但只答对了一半。真正的边界是下面这张表修饰符同一个类内同一个包内不同包的子类全局public可以可以可以可以protected可以可以可以不行默认包私有可以可以不行不行private可以不行不行不行注意一个容易记混的点protected能“跨包访问”的前提是你访问的这个对象是子类实例而且是在子类内部通过继承关系去访问。不是说你在任何地方拿一个父类引用就能访问它的protected成员。这个细节坑过不少人我放到下面单独说。2.2 protected 的“拧巴”属性protected是四个权限里最微妙的一个。它允许同包的类访问也允许不同包的子类访问但不同包的子类访问时有一条硬规矩要访问的是继承过来的那个成员本身得通过子类类型的引用来操作。看下面的场景package a; public class Parent { protected int money 100; }package b; import a.Parent; public class Child extends Parent { public void ok() { money 50; // 可以子类内部直接访问继承来的成员 } }但是package b; import a.Parent; public class Other { public void demo() { Parent p new Parent(); // p.money 30; // 编译不过不同包里不能拿父类引用直接访问protected成员 Child c new Child(); // c.money 30; // 编译不过同样是不同包不能通过子类实例访问继承的protected成员 } }为什么最后一行也不行因为在Java的规则里protected在跨包场景下只保护“子类自己内部”的访问视角——子类在自己肚子里能用这个继承来的成员但子类对外不负责“销售”这个成员。说得再直白一点权限是给继承者本人的“内部权限”不是给继承者去代理给别人用的。这个规则看起来绕其实是有道理的。否则protected就等于“只要我愿意继承这个类我就能把这个成员泄露给全世界”那它跟public就没什么区别了。理解了这一层你在设计继承体系的时候就会更谨慎到底要不要放protected放了之后别人继承你的类会有什么连锁影响。2.3 包私有的隐蔽价值访问权限设计中最被低估的其实是默认权限——也就是什么都不写、不加任何修饰符的情况。很多新手以为“不写就是没有权限控制”实际上它是实实在在的包私有只有本包内部能访问。我在实际项目中经常利用包私有来做一种设计把某个模块的“内部零件”只开放给同一包下的其他类。比如一个解析器对外只有一个Parser类是public的剩下的TokenDecider、SyntaxSplitter这些辅助类全部做成包私有甚至它们的构造器也放着不写public。这样从外面看整个解析器只有一个入口内部怎么折腾都行改动辅助类完全不影响调用方重构自由度高很多。这种做法在框架设计里特别常见。你去翻一些开源库的源码会发现真正public的类只占少数大量工具类、内部实现类都是默认权限。对比起来如果一开始图省事全写成public后期这个类一旦被外部代码依赖想缩权限就只能破坏性升级很难受。2.4 权限的“最小暴露原则”不是怕泄密是怕牵一发动全身很多人在争论“字段到底要不要全部privategetter/setter”。我要说private不是银行的保险柜它防的不是恶意攻击者而是防止别人在本不该依赖的地方产生依赖。假设你要改一个类的内部缓存策略原来用HashMap后来发现并发场景不合适得换成ConcurrentHashMap。如果这个字段是public的凡是直接访问过这个字段的调用方全得跟着改如果它是private的你只需要保证外部方法的语义不变内部实现随便换。所以“private”保护的并不是数据本身而是你将来修改代码的自由——这是封装最有价值的地方。给一个我自己常用的判断标准方法只是模块内部协作用的能放包私有就不要public字段几乎一律private需要拿出来看时给getter需要被人改时给setter并想想“是不是有更好的命令式方法”protected只在明确设计继承扩展点时使用不要因为“以后可能有人继承”就提前滥用。访问权限其实是一个“代码沟通协议”它告诉后来者哪些东西你可以安心踩着走哪些只是路过不要碰。协议越清晰代码的长期可维护性越高。3. 方法重载同名方法的“多面人生”3.1 到底什么叫重载编译器怎么认方法重载Overload的定义一句话就能说清**同一个类里方法名相同参数列表不同各方法之间彼此独立。**参数列表不同可以是参数个数不同可以是参数类型不同也可以是参数顺序不同——只要能让编译器区分出来就算重载。注意重载跟返回类型没有关系。你不能写两个方法一个int foo()一个String foo()参数完全相同试图用返回类型来区分。编译器一看签名方法名参数类型列表都一样直接判定重复定义。原因也简单方法签名是编译器判断“你到底调哪一个”的依据而返回类型在调用时经常被忽略比如foo(); // 返回值没用到你让编译器怎么猜根本没法猜。所以记住第一条铁律方法签名里不包含返回类型返回类型不同永远不能构成重载。再看重载的典型场景。同样一个createUser方法参数不同行为略有差异public User createUser(String name) { return createUser(name, null); } public User createUser(String name, String nickname) { return createUser(name, nickname, null); } public User createUser(String name, String nickname, int age) { // 真正执行创建逻辑 }这段代码最大的好处是调用方只需要记住一个方法名按自己拿得到的信息选参数最少的版本内部再统一收敛到最终实现。这也是一种“API连贯性”设计对外接口保持同一个动词不同场景用参数作区分。3.2 自动装箱把重载变成了“视力测试”Java的基本类型和包装类型会自动转换这在重载场景下会引出很微妙的坑。最常见的就是null参数的“薛定谔选择”问题。public class OverloadDemo { public void show(int a) { System.out.println(int: a); } public void show(Integer a) { System.out.println(Integer: a); } public static void main(String[] args) { // show(null); // 编译错误ambiguous, 类型不明确 } }为什么show(null)直接报歧义因为null既可以被当成int的自动装箱目标也可以被当成Integer的引用类型参数编译器在两个候选之间完全没有优先级可依据干脆拒绝编译。这个错误在IDE里非常常见你写的时候觉得“应该会选包装类型吧”真实情况是Java压根不给你这个“应该”。再往深一层基本类型之间的自动升级也会参与重载选择。假设有这两个方法public void print(short s) { ... } public void print(int i) { ... }调用print(1)时因为字面量1默认就是int所以会精确匹配print(int)不会去找print(short)。如果是print((short) 1)才会匹配到print(short)。重载的选择规则是“精确匹配优先找不到精确匹配再考虑扩展”比如public void print(long l) { ... } // 调用 print(1)1 是 int没有 print(int) 时才会自动升到 long这个过程叫基本类型拓宽转换也是重载匹配规则的一部分。平时写代码很少用到这么细的层次但一旦出现莫名其妙的编译选择就要怀疑是不是自动装箱和类型拓宽在捣乱。3.3 可变参数重载世界里最容易被绕晕的玩法可变参数int... args在重载里是最容易出歧义的语法糖。它的本质是一个数组参数但调用时可以像列表一样传任意多个值也可以完全空着。public class VarargsDemo { public void test(int... nums) { System.out.println(varargs); } public void test(int n) { System.out.println(single); } public static void main(String[] args) { test(10); // 输出 single精确匹配优先于可变参数 // test(); // 编译错误无法区分是调用空的可变参数还是别的 } }test(10)为什么输出single因为Java的匹配规则里固定参数的方法优先于可变参数方法。换句话说人能一眼看出来“哦你是想传一个数”编译器也一样它会优先选不需要把参数包成数组的那个。但test()就麻烦了可变参数版本允许空参数假如方法集里没有其他零参数同名方法编译器是能接受的会当可变参数为空数组来处理可如果同时存在一个test()编译器同样会困惑。所以在设计可变参数重载时记得留点空白给编译器也留点清醒给自己可变参数方法的多个重载版本很容易出现公共调用集测试时一定要把边界值考虑进去。3.4 重载的“语义一致性”才是设计灵魂从语言层面来说重载的门槛很低——参数不同加上方法名相同就算。但从工程层面说重载不是让你随便起一堆同名方法的通行证。同一个方法名被重载的每一组参数都应该在语义上能归到同一个概念。save()保存数据、save(String name)保存并给数据命名、save(String name, boolean overwrite)保存时是否覆盖——这些都在“保存”这个动作的合理范围内。但如果一个方法叫calc一个版本算利润另一个版本却去更新数据库那就属于重载的滥用。调用方只知道名字一样很容易在错误的地方调出意外的行为这种代码本质上是一种“安全陷阱”。我见过一些老代码同一个方法重载了七八个版本参数从int到String到Object到接口实现逻辑还各种分叉维护起来非常痛苦。重载的正确姿势更接近“收敛”而不是“发散”多个版本最终应该统一汇聚到同一个核心实现上这样核心逻辑只改一处其他重载版本只是个参数适配的壳。4. 重载和重写双胞胎容易认错的两个地方4.1 一个看编译期一个看运行期落脚点完全不同方法重写Override发生在子类和父类之间子类重新定义了父类的某个方法方法名、参数列表、返回类型或返回类型的子类型都保持一致访问权限不能比父类更严。这里最容易出事的区分点是重载是同一个类里“多一个方法”重写是父子类之间“替换一个方法的实现”。你可以在子类里同时看到三种情况class Parent { public void work() { System.out.println(parent work); } public void work(String name) { System.out.println(parent work: name); } } class Child extends Parent { Override public void work() { System.out.println(child work); } public void work(int times) { // 这是重载子类新增了参数为 int 的 work } }上面这段代码里child.work()调用的是子类覆写后的版本child.work(xxx)调用的仍然是父类的版本child.work(3)则是子类自己新增的重载方法。这三条调用路径混在一起新手经常分不清哪个是哪个。好用的判断口诀是**方法签名变了就是重载方法签名一模一样只是换了实现体就是重写。**跟你是谁没关系跟在哪里写的也没关系只看签名。4.2 Override 这个“逃犯识别器”一定要用有没有Override注解运行效果一模一样。也就是说即使你不写这个注解正确的重写也能正常执行。那它的价值在哪Override是一个编译期检查器——它会强制编译器去确认“这个方法确实是重写了父类或接口的某个方法”。如果你原本想重写却不小心把参数类型写错了方法就变成了重载编译器不会报错程序跑起来自然也不会调用你写的这个“伪重写”方法。但加了Override之后编译器直接提示“没有找到要重写的方法”你当场就能抓住这个低级错误。这个坑我真实踩过。曾经想覆写某个方法手滑把参数从Object写成了String编译顺利通过运行时却一直走父类逻辑排查了好久才发现方法根本没重写成功。从那以后我的习惯是只要子类里出现一个跟父类同名方法的意图一律先写Override让编译器替我把关。4.3 多态下的动态绑定调用哪个方法编译器说了不算方法重载与重写交叉在一起时会出现经典的“动态绑定”问题。class Animal { public void speak() { System.out.println(animal speak); } } class Dog extends Animal { Override public void speak() { System.out.println(dog bark); } } public class Demo { public static void main(String[] args) { Animal a new Dog(); a.speak(); // 输出 dog bark运行时看的是实际对象类型 call(a); // 输出动物在叫 call(new Dog()); // 输出狗狗叫 } public static void call(Animal x) { x.speak(); } public static void call(Dog x) { System.out.println(狗狗叫); } }第一处a.speak()变量声明类型是Animal但实际对象是Dog方法执行时JVM根据对象真实类型找到Dog.speak所以输出“dog bark”这就是重写的动态绑定。第二处和第三处更有意思call(new Dog())时编译器会根据参数类型选择call(Dog)这个重载版本走的是编译期静态绑定跟运行时对象真实类型没半毛钱关系。可一旦进入call(Animal x)方法体内部x.speak()又走动态绑定回到Dog的实现。这种“重载看编译期声明类型、重写看运行期实际类型”的混合规则是很多多态相关拦截问题的根源。理解它你才算真正把这章学透了。5. 工程实战里可以少踩的坑5.1 包结构设计先于写代码听起来像废话但真没几个人做到新手写项目经常是类写完了一堆文件夹乱七八糟最后看目录自己都皱眉头。包结构的核心原则是**“依赖方向清晰”**业务模块包不能反过来依赖工具包里的接口去实现自己的核心逻辑核心领域包更不该去依赖那些只在内部分层使用的解析包。举一个我见过的失败案例某项目把所有的工具类一股脑丢在util包结果util包不到半年膨胀到一百多个类好几个类还反向依赖业务模块的类导致每次想重构任何一个业务模块都牵连着一堆工具类。正确做法是按功能域分包订单相关的放order支付相关的放payment每个功能域内部再分出api、service、dao、model等子包。这样模块边界清楚包与包之间的依赖图才不会变成一团乱麻。还有一点容易忽略包之间的访问权限配合。两个分层包之间对外暴露的类用public、对外暴露的方法用public其他一律收紧。如果有一天你要换掉底层实现改动范围能控制得很小就是因为外面的包根本没有能力触达内部的“零件”。5.2 重载的数量不是越多越好命名才是最便宜的沟通成本我自己的重载设计原则是“先少后多按需重载”。一开始只提供最常用的参数版本等到真实调用方有明确需求时再补新版本不要一次性把所有可能参数组合全铺开。原因很现实每多一个重载版本阅读者就多看一条分支如果五个版本里有三个根本没被调用那就是纯噪声。比较稳妥的做法是把核心实现封装成一个带完整参数的方法其他重载版本都往这个方法汇聚public User createUser(String name) { return createUser(name, 0, null); } public User createUser(String name, int age) { return createUser(name, age, null); } private User createUser(String name, int age, String remark) { // 真正逻辑在这里其他重载调用它 }这样真正复杂的方法被控制成private或包私有对外只有简洁的“半成品壳”未来要加参数只在中间层新增一个重载并统一转向完整的私有方法即可。整条链路好维护也不容易漏改逻辑。5.3 权限与“以后可能会用到”为什么会成为技术债的温床“权限放得宽一点吧以后可能会用到”——这句话几乎在每个项目评审里都能听到也是我眼里最典型的技术债脚本。权限一旦放开调用方就可能产生依赖依赖一旦形成你后来的每一步重构都得考虑兼容成本。所谓“以后可能用到”往往根本没发生等你真要用的时候你直接加一个public方法都比无脑放大既有权限更可控。根据我的经验最能减少争议的办法是让访问权限成为设计方案的一部分而不是写完代码后的补丁。设计类的时候先把“外部要用的接口”列出来这些方法设成public类与类之间的协作方法设成包私有字段一律private。然后再按包分层把不同包的“合作契约”明确下来。这个过程只需要动笔几分钟收益却贯穿整个项目生命周期尤其是别人接你的代码时部署边界一眼就能看出来。5.4 说到最后重载使用体验上还有几个“直觉反例”重载再常见也有一些反直觉的边角值得写代码时心里挂个号null值调用重载方法大概率触发歧义编译错误遇到时别硬猜显式强转一下类型比如foo((String) null)。可变参数的数组展开在重载里会触发“先精确后可变”的规则如果你想强制走可变参数版本就显式传一个数组。泛型类型擦除会让两个看似不同的重载“撞车”比如print(ListString)和print(ListInteger)在编译时会变成同一个签名直接编译失败必须在命名上区隔开。重载方法里使用基本类型和包装类型混搭时记得测空值空指针永远比编译错误难查得多。最后分享一点个人感受包、访问权限、方法重载这三件事单独拉出来每一个都不难难的是把它们串起来想问题了。包决定代码模块的边界权限决定模块之间信息的可见度重载决定了同一个入口的包容度。设计一个类甚至一个系统的时候这三样东西其实是同一件事的三个视角——你在构建一个“对外清晰、对内自由、变化可控”的结构。写小练习的时候多纠结几回真正做项目的时候就能少折腾几轮。
