API不是从业务抽象出来的(2)：举例说明实战视频课程

直面接口设计与业务逻辑的断层

不少开发者在转岗做架构或写底层框架时，总会遇到一种卡壳感：业务代码写得滚瓜烂熟，可一旦要求把具体功能提炼成通用 API 供外部调用，写出来的接口往往僵硬且强耦合，稍微变动一处需求就得全盘推倒重来。这门课直击的正是“API 不是从业务抽象出来的”这一反直觉痛点。它不教基础语法，也不讲怎么调现成轮子，而是拿 Android 的 ListView 当解剖样本，硬核拆解一个成熟接口到底是怎么从无到有造出来的。适合有实际业务开发经验、但对框架级 API 设计缺乏体系认知、想补全架构设计能力缺口的中级程序员。

从造形思维到代码落地的拆解

看这份资料，建议先别急着翻最后的代码范例。第一节和第二节是整门课的题眼，必须先看透“EIT 造形”这个核心概念。高焕堂提出的 EIT 模型，本质上是为了打破“从业务流程硬推接口”的惯性思维，教你如何用父类、子类和引擎之间的互动关系来搭接口骨架。把这个造形吃透后，再带着理论框架去看第三到第五节。这几节以 ListView 为例，把接口设计拆成了“两种知识的分析”和“特殊化设计”。你要重点观察：通用知识（框架定死的规矩）和特殊知识（业务自己变动的部分）在代码里是怎么被物理隔离的。看完这几节，你应该能回答一个关键问题：为什么不能把业务逻辑直接写进基类，而必须通过 API 留出让子类去填的“空隙”？

学完能做什么与资料怎么练

学完这套内容，你绝不仅仅是会背 EIT 概念，而是能独立干一件具体的架构活儿：面对一个全新的业务场景，能主动画出接口的留白处，设计出不让外部调用方感到混乱的 API 层级。为了达到这个效果，配套练习必须这么练：拿到资料包里的 ListView 代码范例后，先别运行，自己照着 EIT 结构在纸上画出类图，标出哪里是接口、哪里是特殊化实现；然后再跑代码验证。最后，给自己加个码——尝试把 ListView 的接口设计思路，平移到 RecyclerView 或者任意一个带列表渲染的自定义控件上，自己写一版接口骨架。只有能照葫芦画瓢写出新框架的 API 留白，才算真正补齐了这块架构短板。