软件架构风格之调用返回风格：主程序、面向对象、分层，到底怎么区分？
软件架构风格之调用返回风格：主程序、面向对象、分层，到底怎么区分？
备考软考架构师的时候，调用返回风格（Call-Return Style）这块总是搞混。主程序/子程序、面向对象、分层架构，它们都算调用返回风格，但考试问你"这段描述属于哪种子风格"——瞬间就懵了。
这篇文章用最直白的方式，把它们的区别讲清楚。
一句话说清楚
调用返回风格的核心思想：一个模块调用另一个模块，被调用的模块执行完把结果返回给调用者。就这么简单。
但同样是"调用-返回"，组织方式不同，就分出了不同的子风格。
主程序/子程序风格
这是最原始的一种。结构就是：
主程序 ├── 子程序A ├── 子程序B │ └── 子程序C └── 子程序D特点：
- 一个主程序控制全局，调用各个子程序
- 子程序之间也可以互相调用
- 数据主要通过参数传递
- 全局变量是"共享数据区"
典型场景：早期的 C 语言程序、Shell 脚本、批处理流程。
识别关键词：主程序、子程序/子函数、全局数据区、单线程控制。
面向对象风格
这是现在最主流的一种。把数据和操作封装成对象：
对象A（数据 + 方法） │ 调用 对象B（数据 + 方法） │ 调用 对象C（数据 + 方法）特点：
- 数据和对数据的操作封装在一起（封装）
- 通过继承复用代码
- 通过多态实现灵活调用
- 对象之间通过"消息"（方法调用）通信
典型场景：Java、C++、Python 写的绝大多数业务系统。
识别关键词：对象、类、封装、继承、多态、消息。
敲黑板：面向对象也是调用返回风格！只不过调用的是"对象的方法"。
分层架构风格
把系统按职责分成若干层，每层只调下一层：
表示层（UI） │ 调用 业务逻辑层（Service） │ 调用 数据访问层（DAO） │ 调用 数据库特点：
- 严格分层：第 N 层只能调第 N-1 层
- 每层只负责一类事情，职责清晰
- 层与层之间通过接口通信
- 修改某一层的实现，不影响其他层
典型场景：Web 应用（Controller → Service → Repository）、OSI 网络七层模型。
识别关键词：分层、N层架构、层间接口、逐层调用。
一张表搞定区别
| 维度 | 主程序/子程序 | 面向对象 | 分层 |
|---|---|---|---|
| 组织核心 | 功能分解 | 对象/类 | 抽象层次 |
| 耦合方式 | 参数+全局变量 | 方法调用 | 层间接口 |
| 数据共享 | 全局数据区 | 对象内部私有 | 层内共享 |
| 扩展方式 | 加子程序 | 继承/组合 | 插入新层 |
| 典型例子 | C程序 | Java项目 | Web三层架构 |
考试怎么答
软考经常这么出题：
“某系统采用分层结构，将业务逻辑、数据访问和界面展示分离” —— 这是分层架构风格。
“系统由多个对象组成，对象之间通过消息传递进行通信” —— 这是面向对象风格。
“系统有一个主控模块，通过调用子函数完成计算” —— 这是主程序/子程序风格。
记住口诀：看组织方式——是功能拆解（主程序）、对象封装（面向对象）、还是层次抽象（分层）。
写在最后
说实话，这三种风格在实际项目中经常混着用。比如一个 Spring Boot 项目：整体是分层架构（Controller→Service→DAO），但每一层内部用的是面向对象风格，某个工具类可能又是主程序/子程序风格。
考试归考试，实际干活不用死抠定义。但考试要过，这些概念还是得门儿清。
有问题评论区聊。