先看一次调用：任务交出去，执行权再回来
视频把调用—返回定义为一条明确的执行关系：调用方调用函数、过程或方法，执行权转到被调用方；被调用方完成任务后，执行权回到调用方，并可带回结果。关键不只是把代码拆开，还在于谁决定下一步执行什么，以及完成后回到哪里。
讲者用“分而治之”解释这种结构的动机。复杂任务被拆成职责清楚的小任务，模块通过接口协作；调用者知道怎样使用子任务，却不必同时理解每个子任务的内部细节。拆分、解决、再组合，构成这类架构的基本节奏。
从重复代码和跳转，走向有边界的过程
讲者先回顾早期线性指令和大量跳转带来的维护困难：程序规模变大后，重复操作散在各处，控制路径像面条一样交错。子程序把常用操作抽出来，调用后能返回原处，是把大任务拆成小任务的早期做法。
随后，高级语言中的函数与过程、结构化编程中的顺序/选择/循环，以及面向对象中的方法调用，沿着不同的编程方式继续使用调用—返回机制。视频把这段历史与“软件危机”联系起来：当项目更大、更难维护时，清晰的模块边界和执行路径成为工程需求。
分而治之要能组合，接口就成为契约
讲者从认知负担谈起：程序员很难同时把数千行逻辑放在脑中，于是先把需求分成可处理的子问题，分别实现，再通过调用关系合成完整任务。主程序调用子程序、子程序继续调用下一层，形成由上到下的分解和由下到上的结果汇总。
复用让这套机制更有价值。数学计算、排序、日志或数据库访问可以封装成库，新的程序直接调用。要让调用者放心使用，函数声明需要交代参数和返回结果；调用者依赖这个接口，具体实现可以留在模块内部。讲者由此引出信息隐藏与关注点分离。
设计时还可以先写高层调用骨架，再逐步决定底层实现。例如先确定需要“排序”这一步，之后再选择具体算法。这是视频所说的自顶向下、逐步求精。
调用栈保存“从哪里回来”
分解后的子任务可以一层层调用，因此运行时必须记住每一层尚未完成的工作。讲者用调用栈说明：调用时保存返回位置以及与本次调用有关的局部上下文；最深的一层先完成并返回，外层再接着执行。
视频用入栈、出栈来对应调用与返回。这个模型解释了为什么主程序可以暂时让出执行权、之后又从原来的位置继续。这里应把调用栈理解为常见的运行时实现机制；视频中的“硬件天然契合”是讲者对实现关系的概括。
主程序—子程序：谁是构件，谁连接它们
视频随后从软件体系结构的角度命名这些部分：函数、过程或方法是执行具体任务的构件；构件之间的连接是调用以及返回时的控制转移。讲者把这种以控制流组织模块的方式，与前一讲以数据到达驱动处理单元的数据流风格作对照。
主程序—子程序是这里的典型形式。一个入口负责整体顺序，按需要调用子程序；子程序还可继续调用下一层，完成后沿调用路径逐级返回。视频反复强调三个特点：层次化分解、可追踪的执行路径，以及主程序对总体顺序的控制。
设计顺序也对应运行顺序：先从整体功能划分任务，再逐层细化职责；运行时由入口发起调用，最终回到入口完成收尾。
执行顺序清楚，但扩展与交互会变难
讲者认为主程序—子程序适合顺序、确定、一次性完成的任务：结构好理解，调试直接，函数可复用，在资源受限场景也容易控制开销。他列举系统软件、嵌入式程序、算法计算和业务处理等应用领域。
同一套显式调用也带来边界：主程序若必须知道每个被调用者，新增功能常要改动既有调用链；模块之间通过参数或共享数据传递状态，接口和数据可能耦合。视频还讨论同步执行下的并发、失败恢复、交互和事件触发需求，以及函数拆得过粗或过细的问题。讲者用“上课铃响后学生各自反应”说明某些场景更适合由事件触发参与者，而不是中心逐个点名。
这些是对该组织方式的取舍描述，不等于任何使用函数的程序都无法并发或恢复。视频的比较对象，是由中心顺序协调、依赖显式同步调用的整体架构。
面向对象把数据与处理它的行为放到一起
接下来，讲者把视线从“要执行哪些步骤”转向“系统里有哪些实体，各自负责什么”。在以过程为中心的设计里，功能分成多个子程序，数据可能由参数或共享结构传递。业务实体的字段一旦变化，多处读写它的函数都可能需要调整。
面向对象的回答是把状态与操作这些状态的方法封装在对象中，由对象对外提供协作接口。视频用账户的余额、存钱和取钱解释这种组织方式，并介绍封装、继承、多态和抽象如何服务于复用与演化。讲者也提醒，这种方式是为了改善特定的维护问题，并非只要换成类就会自动降低耦合。
借书系统：同一业务，两种职责划分
视频用图书馆借阅系统把区别落到具体代码组织上。主程序—子程序版本从 main 出发，依次检查图书、验证用户资格、更新库存；BookData 和 UserData 作为数据结构供多个过程使用。如果图书标识从数字改成字符串，查询、入库、借出等处理路径都可能受影响。
面向对象版本先找书、读者和借阅记录等对象，再安排各自的状态与方法。讲者以“书知道自己是否已借出，并更新自己的状态”说明封装；读者借书时，相关对象通过方法协作。这里的重点不是消除执行顺序，而是把数据修改责任放回拥有数据的对象附近。
对象之间的方法调用，仍然是调用—返回
讲者回顾 Simula、Smalltalk 到 C++ 和 Java 的发展后，给面向对象架构对应的构件与连接件：对象是构件，对象之间的方法调用是主要连接方式，接口与协作要求约束它们怎样配合。对象有自己的状态和行为，调用方经接口请求其完成工作。
因此，两种组织法虽分别侧重功能分解和对象职责，运行时仍能看到“一个部分调用另一个部分，完成后返回”的控制关系。视频还举图形界面、企业业务、游戏对象和仿真实体为适用领域。
选风格时，要看业务实体、变化与运行约束
最后，讲者归纳面向对象的长处：把相关数据和行为聚在一起，便于按业务实体建模、分工、维护和扩展。同时，他也列出对象与动态绑定可能增加的开销、过度设计和学习成本。设计不当时，类层次本身也会成为维护负担。
他的选择建议是：当实体与协作关系清楚、需求持续变化、团队需要稳定接口时，面向对象有优势；以高性能计算、实时处理或纯数据管道为主的任务，则要审视它的成本。微服务内部仍可用对象，服务之间却应以服务契约、API 或事件连接，而不把进程内对象调用直接当成跨服务通信。
视频以“没有银弹”收束：主程序—子程序与面向对象都继承了拆分复杂问题的思路，区别在于模块围绕功能还是围绕拥有状态的对象组织，以及这种组织是否适合当前的变化和执行方式。
