企业官网建设流程全解析

简介：Java 面向对象编程中，封装、继承、多态是初学者最容易混淆的核心概念，这份实例解析 PDF 面向正在学习 Java 基础或准备复习面向对象特性的读者，帮助理解三大特征在真实代码中的具体落点。资源以单个 PDF 文件提供，压缩包大小约 49KB，轻量易读，适合快速浏览并对照代码练习；目前已有 5578 人学习/下载，说明其内容具备不错的参考价值。文档从 Teacher 与 Student 两个类的封装写法讲起，演示 private 属性与 getter/setter 方法的配合，同时给出 toString 重写示例；随后通过 Play 基类与 TaoistPriest、Master 等子类的继承关系，展示 extends 关键字的用法以及后续多态扩展思路。读者可以从中获得带运行输出的完整代码片段、测试类示例与输出结果，既能理解封装如何保护对象内部状态，也能掌握继承与多态的代码组织方式，适合作为课堂笔记补充或自学速查。

1. 实例驱动的 Java 面向对象编程：封装、继承与多态的真实关系

把“封装、继承、多态”背成简答题的答案，最多只能过面试第一轮。真正拉开差距的是：看到一个需求时，能判断哪些字段该私有、哪些行为该收口；能说清父类构造器里调用被子类重写的方法会发生什么；能指着某一个对象说明白编译期它是什么类型、运行期它又是什么类型。这里用一组可运行的 Java 实例，把三大特性放进具体业务场景里逐一拆开，并给出编译命令、输出结果和边界条件。适合准备 Java 面试的开发者、刚学完语法想建立对象设计直觉的初级工程师，以及需要做代码评审的在职工程师。

2. 封装：先圈定最小可见范围，再设计对外行为

2.1 为什么封装是第一道边界：从字段访问到对象状态

翻开源码，很多人觉得“把字段 private 就是封装”。实际上 private 只是访问控制的第一步，封装要解决的是对象状态的合法性与变更路径。一个 Account 对象如果允许外部直接修改 balance 字段，就无法阻止扣款后余额变成负数；如果通过方法变更，就能在校验、日志、事件通知之间做取舍。从这个角度看，封装把“对象可以怎么被使用”和“对象内部如何存储”拆成两层，调用方依赖的是行为契约而不是字段布局。

Java 的访问修饰符是这条边界的第一层表达。private 仅同类可见，default 同包可访问，protected 同包或子类可访问，public 全可见。实际编码时，字段默认用 private，需要被子类读取的用 protected，跨包协作才用 public 接口。把修饰符当作声明边界的工具，而不是代码风格的要求。

这个表看似基础，但它回答了面试中常问的“protected 到底在什么范围可见”。真正的边界不只是语法，而是把状态变更收口到受控方法里，后续加缓存、加幂等、加审计都不需要调用方配合。

2.2 用 getter/setter 与构造器搭一个可复现的封装实例

下面是一个包含构造校验、更新校验与只读视图的 Account。保存为 Account.java，重点看字段权限和状态变更方法。

import java.math.BigDecimal; import java.util.ArrayList; import java.util.Collections; import java.util.List; public class Account { private final String accountNo; private BigDecimal balance; private final List<String> history = new ArrayList<>(); public Account(String accountNo, BigDecimal initBalance) { if (accountNo == null || accountNo.isBlank()) { throw new IllegalArgumentException("账号不能为空"); } if (initBalance == null || initBalance.signum() < 0) { throw new IllegalArgumentException("初始余额不能为负数"); } this.accountNo = accountNo; this.balance = initBalance; } public BigDecimal getBalance() { return balance; } public List<String> getHistory() { // 返回只读视图，调用方不能 add/remove 内部集合 return Collections.unmodifiableList(history); } public void deposit(BigDecimal amount) { if (amount == null || amount.signum() <= 0) { throw new IllegalArgumentException("充值金额必须大于 0"); } balance = balance.add(amount); history.add("deposit:" + amount); } public void withdraw(BigDecimal amount) { if (amount == null || amount.signum() <= 0) { throw new IllegalArgumentException("取款金额必须大于 0"); } if (amount.compareTo(balance) > 0) { throw new IllegalStateException("余额不足"); } balance = balance.subtract(amount); history.add("withdraw:" + amount); } }

再建一个运行入口 AccountRunner.java，验证外部无法通过状态变更入口破坏余额约束：

import java.math.BigDecimal; public class AccountRunner { public static void main(String[] args) { Account acct = new Account("1001", new BigDecimal("100")); acct.deposit(new BigDecimal("50")); System.out.println(acct.getBalance()); // 触发余额校验分支，验证非法操作被拦截 try { acct.withdraw(new BigDecimal("200")); } catch (IllegalStateException e) { System.out.println("取款失败: " + e.getMessage()); } System.out.println(acct.getHistory().size()); } }

编译并运行：

javac Account.java AccountRunner.java java AccountRunner

输出三行，依次是 150、取款失败: 余额不足、1。balance 没有 setBalance，外部只能通过 deposit 与 withdraw 两个行为路径改变状态，这就是封装的目标。参数说明：金额用 BigDecimal 而不是 double，因为货币计算要避免浮点误差；signum() 返回 -1、0、1，用来判断正负比 compareTo 更直观；getHistory 返回的 unmodifiableList 是视图，不是副本，原集合仍只能被 Account 自己修改。

注意，getter 返回内部集合的常见替代方案是返回new ArrayList<>(history)，即快照。只读视图更省内存，但暴露的是动态视图；快照能保证调用方看到的是某个时间点的状态。按业务需要选，这不是绝对对错。

2.3 封装的三个常见误用与排查

第一个误用：setter 里只做this.balance = balance，没有任何校验。这样的 setter 和 public 字段没有本质差别，只不过把赋值语法换成了方法调用。代码评审时看到“空 setter”，要么补校验，要么删除并改成行为方法。

第二个误用：getter 直接返回内部集合或数组。调用方拿到引用后可以 add/remove，绕过封装。上面的例子用Collections.unmodifiableList(history)兜底，数组则可以用clone()或Arrays.copyOf返回副本。还有一个容易忽略的点：返回不可变集合时，元素对象本身仍然可能被修改，所以要确认元素是不是不可变类型。

第三个误用：在构造器内调用可重写方法。由于 Java 在构建对象时会动态绑定到子类实现，而子类字段此时尚未初始化，可能读到 null 或 0。这个问题的完整表现会在 3.3 里展开，修法是构造器只调用 private、final 或 static 方法，把多态调用放到初始化完成之后。

排查这类问题时，我一般会在状态变更方法入口打断点，先看入参是否被立刻写进字段，再追一层调用链，判断有没有绕过变更入口。多线程场景下，无同步的可变 setter 还有可见性问题，优先考虑用不可变对象或明确写入同步策略，而不是靠 setter 满天飞来补状态。

3. 继承：复用与重写的边界，别把继承用成组合

3.1 继承的语义与 Java 的规则

继承表达 is-a 关系：Manager is a Employee。子类复用父类字段与方法，也可以重写方法改变行为。Java 的类继承是单继承，一个类只能有一个直接父类；接口可以多实现。单继承减少了菱形冲突，但也提高了设计约束，所以接口在 Java 中承载了更多“能力组合”的功能。

重写不能凭感觉写。方法签名要保持一致，访问修饰符不能比父类更严格，返回类型可以缩小（协变返回），受检异常不能比父类更宽。给重写方法加@Override注解，编译器能在签名不一致时立刻报错，比运行时才发现问题便宜得多。下面是一张常用的重写检查表：

提示：真实项目中一个 public 类型对应一个源文件；为压缩示例篇幅，下面的代码把非 public 类放在同一个文件中，方便直接 javac 跑通。

3.2 一个从基类到子类的可运行继承示例

把两个子类放进同一个 Main.java，是为了让示例一键编译，核心还是看继承与重写如何运作。

class Employee { private String name; private double baseSalary; Employee(String name, double baseSalary) { this.name = name; this.baseSalary = baseSalary; } public double calcSalary() { return baseSalary; } } class Manager extends Employee { private double bonus; Manager(String name, double baseSalary, double bonus) { super(name, baseSalary); this.bonus = bonus; } @Override public double calcSalary() { // 复用父类基础工资计算，再叠加奖金 return super.calcSalary() + bonus; } } public class Main { public static void main(String[] args) { Employee e = new Manager("Kai", 8000, 2000); System.out.println(e.calcSalary()); } }

编译执行：

javac Main.java java Main

输出是 10000.0。这里 Employee 引用指向 Manager 实例，调用 calcSalary 时执行的是 Manager 重写版本。super.calcSalary()不会触发多态，它直接调用父类实现，用来复用基础工资逻辑。参数说明：示例里金额用 double 只是为了演示继承结构，真实结算建议换 BigDecimal；构造器链上，Manager 构造器第一行显式调用了super(name, baseSalary)，如果父类没有无参构造器，子类也必须这样显式调用。

3.3 继承体系里的构造器、字段隐藏与 protected 访问

构造器调用顺序是一条线：先父类构造器，再子类字段初始化，最后执行子类构造器体。这意味着父类构造器执行时，子类字段还没有被赋值。如果把多态方法写进父类构造器，执行到的就是子类重写方法，但子类状态是默认值，很容易出现意料之外的 null 或 0。这也是 2.3 中“构造器内调用可重写方法”在继承体系里的完整表现。

字段隐藏同样容易踩坑。子类声明一个与父类同名的字段，不是重写，而是隐藏。访问哪个字段由引用声明的类型决定，而不是对象的实际类型。所以重写针对方法，不要试图用同名字段覆盖父类字段，这会让同一个对象在不同引用类型下展示不同的值。

protected 的边界要单独划清。同包内可访问，跨包子类内可访问，但跨包无关类不行。还有一个高频考点：Manager 继承 Employee 后，可以通过 this 访问父类 protected 成员，但不能通过另一个 Employee 实例访问。原因是“子类内”这个范围只保护当前继承链上的访问，不能把任意父类实例都当成自己。

3.4 继承还是组合：判定表与一个反例

既然 Java 单继承，继承名额就很宝贵。继承的最强理由是“子类确实是一种父类，且需要以父类引用统一处理”。如果只是想要复用某个方法，组合更安全。

一个常被点名反例是 Stack 继承 Vector。Stack 只需要栈行为，却继承了 Vector 的随机访问能力，调用方可以把 Stack 当 List 用，在中间位置插数据，破坏栈语义。组合方案是内部持有一个 Deque，只暴露 push/pop。这个例子说明：继承不能只看复用，还要看父类的全部公开行为是否都符合子类的语义。

4. 多态：运行时行为由对象决定，编译期行为由引用决定

4.1 多态的两种形态：重写与重载

Java 里的“多态”指同一个方法调用在不同对象上有不同行为。严格区分的话，运行时多态靠重写实现，编译期多态靠重载体现。这两者在面试中常被放在一起比较：

有一个观点需要先说清：如果回答“重载是多态”，可能被面试官追问“绑定发生在什么时候”。更可靠的表述是“重载属于编译期方法分派，重写属于运行期多态”。这样既保留了多态的宽泛定义，又把两种机制的边界讲清楚。

4.2 用接口构建多态示例：Shape 与 area()

这里用一个几何图形面积计算的例子，把“编译期看左边引用、运行期看右边对象”复现出来。

interface Shape { double area(); } class Circle implements Shape { private final double radius; Circle(double radius) { this.radius = radius; } @Override public double area() { return Math.PI * radius * radius; } } class Rectangle implements Shape { private final double width; private final double height; Rectangle(double width, double height) { this.width = width; this.height = height; } @Override public double area() { return width * height; } } public class ShapeMain { static void printArea(Shape s) { // 动态绑定：s 的实际类型决定了调用哪个 area 实现 System.out.println(s.area()); } public static void main(String[] args) { Shape s1 = new Circle(2); Shape s2 = new Rectangle(3, 4); printArea(s1); printArea(s2); } }

编译执行：

javac ShapeMain.java java ShapeMain

输出约 12.566370614359172 与 12.0。printArea 的参数类型是接口 Shape，但运行时传进来的是 Circle 或 Rectangle 实例，JVM 根据对象实际类型决定调用哪个 area()。这是面向对象设计里“依赖抽象而不是具体类”的最小演示。参数说明：Circle 与 Rectangle 都实现了area()，但各自的计算逻辑不同；main 方法里变量声明成 Shape，表示编译期只能保证有 area 方法，真正执行哪个版本由对象决定。

4.3 向下转型、instanceof 与 ClassCastException

向上转型不需要显式写，但向下转型可能失败。比如想调用 Rectangle 独有方法时，直接把 Shape 引用强转成 Rectangle，如果实际对象是 Circle 就会抛 ClassCastException。所以向下转型前要先判断类型。

if (s instanceof Rectangle r) { System.out.println(r.width); }

新版 JDK 的 instanceof 模式匹配把“判断类型、强制转型、变量绑定”三步合并成一步。即使项目还停在旧语法，思路也一样：先 instanceof，再转，再调用子类特有逻辑。与 getClass 判断的区别在于：instanceof 允许子类通过，getClass() 要求运行时类型完全一致。如果多态体系中可能出现子类，用 instanceof 更符合多态语义；如果必须精确到某个类型，用 getClass()。

这里要注意一个反模式：在多态调用点写下向转型，通常意味着抽象设计不够。更好的做法是把子类特有行为收敛到接口方法或抽象方法里，让调用方不需要关心具体类型。向下转型是处理遗留代码的过渡手段，不应成为新代码的主力方式。

4.4 多态在策略模式与框架中的落点

常见做法是定义策略接口，多个实现类在运行时替换。Spring 依赖注入的核心逻辑和上面的 Shape 示例一致：调用方依赖接口，容器把具体实现注入进来。JDK 里的Collections.sort(List, Comparator)也是一个多态点，比较策略换一个实现，排序算法不用变。

多态不是没有代价。引用类型是接口时，只能调用接口上声明的方法，具体类的扩展方法被隐藏；频繁向下转型又会让多态形同虚设。所以设计接口时要收敛方法数量，让实现类可以稳定满足抽象，而不是为了“以后好扩展”塞进一堆用不上的方法。

5. 综合实例：用薪资批量计算串起封装、继承与多态并验证

5.1 需求与类设计

一个很小的需求：计算固定薪资与计件员工的月薪，统一输出姓名和金额。这个规模刚好能把三特性放一起看。Employee 作为抽象基类封装姓名，Manager 与 PieceWorker 继承它并各自重写 calcSalary；批量处理时用List<Employee>装载对象，循环里调用同名方法。

5.2 完整代码与运行结果

import java.util.ArrayList; import java.util.List; abstract class Employee { private final String name; protected Employee(String name) { this.name = name; } public String getName() { return name; } public abstract double calcSalary(); } class Manager extends Employee { private double base; private double bonus; Manager(String name, double base, double bonus) { super(name); this.base = base; this.bonus = bonus; } @Override public double calcSalary() { return base + bonus; } } class PieceWorker extends Employee { private int pieces; private double unitPrice; PieceWorker(String name, int pieces, double unitPrice) { super(name); this.pieces = pieces; this.unitPrice = unitPrice; } @Override public double calcSalary() { return pieces * unitPrice; } } public class Payroll { public static void main(String[] args) { List<Employee> staff = new ArrayList<>(); staff.add(new Manager("Kai", 8000, 2000)); staff.add(new PieceWorker("Lin", 120, 80)); for (Employee e : staff) { // 多态：同一个 calcSalary 调用，执行不同子类版本 System.out.println(e.getName() + ": " + e.calcSalary()); } } }

运行：

javac Payroll.java java Payroll

输出：

Kai: 10000.0 Lin: 9600.0

name 字段是 private final，子类不能直接改，只能通过 getName 读取，这是封装；Manager 与 PieceWorker 复用 Employee 的姓名逻辑，这是继承；遍历List<Employee>时自动执行各自的 calcSalary，这是多态。再新增一种薪资计算方式，只需要增加子类，循环体不用动。

5.3 三道高频面试题与一个验证技巧

第一个问题：子类能重写静态方法吗？不能。子类可以声明同名静态方法，但那叫隐藏，调用哪个由引用类型决定。验证技巧：分别用父类引用和子类引用调用同一个静态方法，打印类名即可看到差异。

第二个问题：为什么构造器里调用重写方法容易出错？因为运行期动态绑定会把调用分派给子类实现，而子类字段还没初始化。验证时给父类构造器和子类字段初始化各加一行日志，观察日志顺序，就能看到那个默认值。

第三个问题：Employee e = new Manager(...)中编译期和运行时分别是什么类型？编译期 e 只能调用 Employee 声明的方法，运行时 e 的实际对象是 Manager。用e.getClass().getName()打印即可确认。

一个快捷验证技巧：需要快速验证多态行为时用 JShell。先定义接口，再在同一个会话里写两个实现类，直接调用方法看输出，比反复 javac 快得多。注意 JShell 会为每个片段自动补全上下文，适合做语法层面的推演，不适合验证依赖注入或容器行为。

本文还有配套的精品资源，点击获取