当前位置：首页 > news >正文

软件工程就是一场“抽象”游戏：从 abstract 关键字到架构设计的认知跃迁

news 2026/4/23 3:48:35

写在前面

“我接触过的抽象，好像就是抽象类和抽象方法。抽象类里只能写抽象方法，子类必须重写。其他地方好像用到的不多……对了，有时候把数据展示给前端，好像也需要‘抽象’一层，返回给前端不同的对象。”

这是很多 Java 初学者的真实困惑。我们把“抽象”理解成了一个语法关键字，而不是一种设计思想。所以当听到“软件工程就是一个抽象的过程”这种话时，总觉得玄乎，和自己写的 CRUD 没什么关系。

但事实上，你每天都在不知不觉地使用抽象——只是你没有意识到。

当你定义List接口而不是直接用ArrayList时，你在抽象
当你把数据库的User实体转换成UserVO返回给前端时，你在抽象
当你编写一个通用的RedisService封装了缓存逻辑时，你在抽象
当你按照三层架构（Controller/Service/DAO）组织代码时，你更是在做宏观的抽象

今天，我们就从“abstract 关键字”出发，一路走到架构设计层面，彻底搞懂：抽象到底是什么？为什么说它是软件工程的核心？Java 开发者如何用好抽象这把利器？

一、什么是抽象？从地图说起

想象你要去一个陌生的城市。你会怎么做？

你会拿到一张城市地图。地图上画了主要道路、地标建筑、公交线路。
但地图上不会画出每一棵树、每一个井盖、每一户人家的窗户。

地图就是现实世界的“抽象”：它保留了关键信息（路怎么走、地标在哪），去掉了无关细节（树木、窗户）。这让你能快速理解城市结构，而不被海量细节淹没。

软件工程中的抽象，本质上和地图一样：忽略与当前目标无关的细节，聚焦于本质特征。

当你调用list.get(0)时，你不关心 ArrayList 内部是数组还是链表——List接口就是抽象
当你发送 HTTP 请求时，你不关心底层 TCP 三次握手——HttpClient就是抽象
当你使用@Transactional时，你不关心事务的开启、提交、回滚细节——Spring 帮你抽象了

抽象的目的不是让代码“变少”，而是让复杂度“可控”。通过分层抽象，我们才能在有限的大脑容量下构建出百万行级别的软件系统。

二、Java 中的抽象语法：abstract 关键字只是冰山一角

2.1 抽象类 vs 接口：纠正常见误区

很多初学者认为：“抽象类里只能有抽象方法，抽象方法必须重写。”

这是错误的。抽象类可以有：

抽象方法（没有方法体，子类必须实现）
具体方法（有方法体，子类可继承或重写）
成员变量、构造器（虽然不能直接实例化，但可以被子类构造器调用）

public abstract class AbstractAnimal { private String name; // 可以有字段 public AbstractAnimal(String name) { // 可以有构造器 this.name = name; } public void eat() { // 具体方法，子类可直接使用 System.out.println(name + " is eating"); } public abstract void makeSound(); // 抽象方法，子类必须实现 }

抽象类和接口的选择原则：

抽象类：用于表示“is-a”关系（猫是一种动物），且需要共享状态或通用行为时
接口：用于表示“can-do”关系（鸟会飞、车能跑），且需要多实现或完全解耦时

Java 8 之后接口可以有默认方法和静态方法，接口的能力大大增强。现代 Java 开发中，接口的使用频率远超抽象类。

2.2 抽象方法的重写：不是“被迫”，而是“填空”

抽象方法强制子类提供具体实现，这其实是模板方法模式的体现。父类定义“骨架”，子类填充“细节”。

public abstract class DataProcessor { // 模板方法：定义了处理流程的骨架 public final void process() { loadData(); processData(); saveResult(); } protected abstract void loadData(); // 子类实现 protected abstract void processData(); // 子类实现 protected abstract void saveResult(); // 子类实现 }

这种设计让核心流程不变，而具体步骤可以灵活替换。你在 Spring 中见过的JdbcTemplate、RedisTemplate都大量使用了这种思想。

三、抽象在开发中的真实应用（你每天都在用）

3.1 面向接口编程：最经典的抽象实践

// 不抽象：直接依赖具体实现 private ArrayList<User> users = new ArrayList<>(); // 抽象：依赖接口 private List<User> users = new ArrayList<>();

为什么第二段更好？因为将来你可以把ArrayList换成LinkedList或CopyOnWriteArrayList，而调用方代码（users.get(0)、users.add(user)）完全不用改。

依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖抽象。你写的 Service 层应该依赖UserDao接口，而不是具体的UserDaoImpl。

3.2 数据交互中的抽象：PO/DO/DTO/VO 的划分

你提到的“把数据展示给前端需要抽象一层”，这正是数据抽象最典型的例子。

PO（Persistent Object）：数据库表结构的一对一映射，可能包含密码、创建时间等内部字段
VO（View Object）：为前端定制的对象，只包含前端需要的字段，可能聚合多个 PO 的数据

如果直接把UserPO（包含password、salt）返回给前端，不仅泄露敏感信息，而且前端可能只需要name和avatar，传输了大量无用数据。

// 不好的抽象：直接暴露内部实体 @GetMapping("/user/{id}") public UserPO getUser(@PathVariable Long id) { ... } // 好的抽象：返回 VO @GetMapping("/user/{id}") public UserVO getUser(@PathVariable Long id) { UserPO po = userService.getById(id); return new UserVO(po.getId(), po.getName(), po.getAvatar()); }

这一层抽象，隔离了内部模型和外部契约，让前后端可以独立演进。