面向对象编程¶Co-authored by Claude

这是华为可信认证的一个科目，本版块梳理面向对象的核心概念、Java 中的落地机制，以及从语法到设计的进阶方向。

面向对象编程（Object-Oriented Programming，OOP）不是"把每个名词都写成一个类"，而是一种组织复杂度的方法：把状态和行为封装在对象里，通过接口约定对象之间的协作，让变化被限制在局部。

学习 OOP 容易停留在语法：会写 class、会 extends、会用 interface，但遇到需求变化时仍然写出牵一发动全身的代码。本页先从概念地图入手，再给出 Java 中的关键机制和常见误区，最后给出学习方向。

概念地图¶

一个常见的误区是把"面向对象"理解为"把过程代码拆进多个类"。判断是否真正面向对象，可以看两点：对象是否封装了不变式，以及调用方是否依赖抽象而不是具体实现。

四大特性¶

封装¶

封装不是给每个字段加 getter/setter，而是保护对象的不变式：对象对外只暴露必要的操作，调用方不能把对象改成非法状态。

public final class Money {
    private final long cents;

    public Money(long cents) {
        if (cents < 0) {
            throw new IllegalArgumentException("金额不能为负");
        }
        this.cents = cents;
    }

    public Money plus(Money other) {
        return new Money(this.cents + other.cents);
    }

    public long cents() {
        return cents;
    }
}

Money 用 final 字段和构造器校验保证"金额非负且不可变"。没有暴露 setCents，调用方就无法绕过校验。封装的关键问题是：这个对象允许处于哪些状态？哪些入口可能破坏它？

继承¶

继承表达 is-a 关系：子类对象在父类出现的地方应当可以替换父类，并且不破坏调用方的预期（里氏替换原则）。

继承的收益是复用和统一类型，但代价也很明显：

• 子类和父类的实现细节耦合，父类改动可能破坏子类（脆弱基类问题）；
• 继承层次过深时，行为来源难以追踪；
• 为了复用代码而继承，往往会把本来不是 is-a 的关系硬凑成继承。

因此有一条常用经验：优先使用组合，只有在确实存在 is-a 且父类为继承设计过时，才使用继承。

多态¶

多态让调用方面向接口编程，运行时再决定执行哪个实现：

interface Notifier {
    void send(String message);
}

final class EmailNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("邮件: " + message);
    }
}

final class SmsNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("短信: " + message);
    }
}

Notifier notifier = new EmailNotifier();
notifier.send("订单已发货"); // 运行时调用 EmailNotifier 的实现

两个容易混淆的概念：

多态的价值在于新增实现时不必修改调用方。如果代码里出现"根据类型写一长串 if-else / switch"，通常说明多态没有被用起来。

抽象¶

抽象是提取稳定契约、隐藏实现差异的过程。Java 提供两种主要表达方式：

选择时可以问：我是在表达"是什么"，还是在表达"能做什么"？ 前者倾向抽象类，后者倾向接口；如果只是需要一份稳定契约，接口通常更灵活。

类之间的关系¶

UML 把对象之间的关系分为依赖、关联、聚合、组合、继承和实现。它们体现的耦合强度不同：

classDiagram
    class Order
    class OrderItem
    class Customer
    class Payment
    class AlipayPayment

    Order "1" *-- "many" OrderItem : 组合
    Order --> Customer : 关联
    Order ..> Payment : 依赖
    Payment <|.. AlipayPayment : 实现

关系选择会直接影响耦合程度：依赖最轻，组合通常比继承更容易替换和测试。设计时不必一开始就画出完整 UML，但应当能说清楚谁拥有谁、谁在什么时候创建谁。

Java 中的关键机制¶

OOP 的概念最终要落到语言机制上。可以按下面的方向建立知识框架：

几个需要特别注意的契约：

• equals 与 hashCode 必须一致：a.equals(b) 为真时，两者的 hashCode 必须相等；否则对象放入 HashMap / HashSet 后可能"找不到自己"。
• 可变对象不适合作为哈希键：作为键之后修改状态，会破坏哈希表的定位。
• == 比较的是引用（或基本类型的值），对象内容比较要用 equals。
• 构造器不是唯一的创建入口：静态工厂方法可以缓存实例、返回子类型、表达更清晰的语义。
• Java 只有值传递：传递对象时复制的是引用值，方法内不能改变调用方的引用指向，但可以修改对象状态（除非对象不可变）。

设计原则：从语法走向设计¶

会写继承和多态，不等于会做面向对象设计。设计原则解决的是"类和对象应该如何划分与协作"：

更完整的内容见软件设计和其中的 SOLID 原则页面。

常见误区¶

学习方向¶

可以按"语法 → 类型 → 协作 → 设计 → 实践"的顺序建立知识体系：

面向对象设计不是一次成型的。更现实的路径是：先写出能工作的代码，再通过重构和测试逐步收敛职责；每引入一层抽象，都要能回答它解决了什么变化。

小结¶

• OOP 的核心不是语法，而是用对象封装状态、用接口组织协作；
• 封装的本质是保护不变式，而不是给字段加 getter/setter；
• 继承表达 is-a，组合表达 has-a，多数情况下组合更灵活；
• 多态让调用方依赖抽象，新增实现时不必修改调用方；
• 抽象类和接口分别偏向"共享实现"和"定义契约"；
• 能写继承不等于会设计，SOLID 原则和重构实践才是从语法走向设计的关键。