SAP稳定抽象原则：稳定性应与抽象化程度一致，等于组件层面的DIP

表现系统高阶架构设计和业务决策的部分不应该经常变更，按[[SDP稳定依赖原则稳定性的量化定义与Fan-in-Fan-out指标]]的逻辑，这些高阶策略理应被放进稳定组件（I=0）里，把想要方便快速修改的部分留给不稳定组件（I=1）。但这带来一个矛盾：如果高阶策略被放进稳定组件，描述这些策略的源代码不就变得极难修改了吗？[[OCP在架构层面的核心机制不想被修改影响的组件应被依赖]]给出了答案——能做到”易于扩展、无需修改”的类，正是抽象类。这就是稳定抽象原则（SAP）的核心：一个组件的抽象化程度应该与其稳定性保持一致——稳定组件应该同时是抽象的，这样它的稳定性就不会牺牲扩展性；不稳定组件则应该包含具体实现代码，这样它的易变性才能通过实际改代码轻松兑现。因此想成为稳定组件，就该主要由接口和抽象类组成，为未来扩展留出空间，这样”既稳定又便于扩展”的组件才能组合出既灵活又不失约束的架构。把SDP和SAP合起来看，本质上就是组件层面的DIP：SDP要求依赖关系指向更稳定的方向，SAP告诉我们稳定性本身隐含着抽象化的要求，两者叠加就等价于”依赖关系应该指向更抽象的方向”。但SDP、SAP与类层面的DIP有个关键区别——DIP作用在类上没有灰色地带，一个类要么是抽象类要么不是；SDP和SAP作用在组件层面，允许一个组件”部分抽象、部分稳定”，可以量化为连续的取值而非非黑即白的判断。