扫码获取 VIP 码
添加管理员微信获取 VIP 码
软件设计师考试中，面向对象设计原则是上午选择题和下午设计题的必考内容。很多考生背下了单一职责和开闭原则这些名词，上了考场却发现命题人根本不考定义默写，而是把原则混在代码片段和设计场景里让你判断。这篇文章回到设计原则的底层逻辑，从每个原则的动机、违反表现、重构方向到关联真题一网打尽，读完你会发现比死记硬背有效得多。
在没有设计原则约束的年代，软件工程师靠直觉写代码。项目初期一切顺畅，功能叠加几次之后，修改一个地方会导致另外三个地方出问题，新增一个需求需要改动七八个类。这种现象被称为模块退化，它的本质不是代码写错了，而是代码的结构在持续变更中丧失了内聚性，耦合度像藤蔓一样蔓延到整个系统。
面向对象设计原则就是为了对抗模块退化而提出的一套准则。最早由罗伯特·马丁在两千年前后系统整理，取五个核心原则的首字母缩写为 SOLID，分别是单一职责原则、开闭原则、里氏替换原则、接口隔离原则和依赖倒置原则。
五个原则有明确的递进关系。单一职责是类的内聚基准线，开闭原则是模块演化的目标状态，里氏替换确保继承体系不崩塌，接口隔离防止客户端被无关方法污染，依赖倒置则是整个体系能够灵活扩展的底层支撑。
在软考体系里，SOLID 的考察分布在两个维度。上午选择题直接考原则的定义和适用场景，题干通常给出一段重构前后的代码对比，要求判断运用了哪个原则。下午设计题中则隐含在方案的评分标准里，一个类承担了过多职责、一个抽象依赖于具体实现、一个子类削弱了父类的契约，都会成为扣分点。理解 SOLID 不是可选项，而是做对下午题的前提条件。
从软件演化规律的视角来看，模块退化通常经历以下三个阶段。第一阶段是职责扩散，一个类开始承担原本不属于它的职责。第二阶段是接口膨胀，为了兼容不同调用方，类的方法签名不断裂变。第三阶段是继承失控，子类通过覆盖父类方法改变了父类约定的行为语义。这三个阶段分别对应了单一职责、接口隔离和里氏替换三条原则的防线。
很多考生分不清设计原则和设计模式的关系。原则是指导思想，模式是工程实践。原则告诉你要追求什么方向，模式给了你实现这个方向的具体手法。软考选择题经常交叉出题，题干描述一个模式但选项里混着原则名称，区分清楚二者是拿分的基础。
单一职责原则的表述极其简单：一个类应该有且仅有一个引起它变化的原因。这里的原因指的是职责，也就是一个类承担的业务责任边界。如果一个类同时管理用户认证和订单结算，那么认证需求的变更和结算需求的变更都会导致这个类被修改，它就有了两个变化原因，违反了单一职责。
什么叫一个职责，这在工程实践中并不总是清晰的。登录和注册算一个职责还是两个职责，答案取决于变更的关联性。如果登录和注册的修改总是同时发生，放在一个类里是合理的。如果在一次迭代中需要改登录流程但不改注册流程，就应该分离。
软考命题人喜欢在这个边界模糊的地方设置陷阱。常见的一种出法是给出一段类图，类名叫用户管理器，里面既有修改密码的方法又有发送短信的方法。命题人的标准答案是违反单一职责，因为密码管理和短信发送属于不同的业务域，触发修改的需求来源也不相同。
违反单一职责的代价不是立刻显现的。项目开始阶段，让一个类多做几件事看起来减少了类的数量，降低了理解成本。但当代码量超过阈值之后，职责混杂的类会变成修改的热点区，每一次需求变更都在这个类上留下疤痕。测试也会变得困难，任何一个行为的改动都可能让不相关的测试用例失败。
识别单一职责边界有一个非常实用的启发式方法。先把类的所有公开方法罗列出来，然后逐个追问自己：这个方法究竟是为哪个角色服务的。如果发现类的方法同时服务于两种甚至三种不同的调用者角色，这就是职责开始分裂的明显信号。比如一个用户服务类中，修改密码是为终端用户服务的，而账号审核通过则是为管理员服务的，这两个方法的调用者角色完全不同，理应将它们拆分到两个独立的类中。在软考下午设计题中看到这样的类结构时，主动提出按角色进行边界拆分的建议是典型的加分操作。
单一职责容易走向一个极端即过度拆分。如果每个类只有一个方法，类的数量会爆炸，模块之间的通信开销超过维护收益。判断粒度是否合理的标准是一个类的所有方法在语义上是否属于同一抽象层级。订单类包含创建订单、取消订单、查询订单是合理的，三个操作都在订单的生命周期逻辑上。但在订单类里加一个生成增值税发票的方法就属于财务域的抽象层级，应该分离。
开闭原则的核心主张是对扩展开放，对修改关闭。翻译成工程语言就是：当系统需要增加新功能时，应该通过新增代码来实现，而不是修改已有的稳定代码。
每一行稳定运行的代码背后都经过了测试用例的反复验证和生产环境的线上考验。修改它们意味着你要重新引入一轮不可控的不确定性，之前通过的所有测试用例都需要重新验证，而在工期紧张的项目中，测试资源从来都是极度稀缺的。工程上的开闭原则本质上是在用接口和抽象层的提前设计投入，来换取未来修改时的安全边际。
在软考的视角下，开闭原则是一个高度可考的编程题切入点。最经典的考法是给出一段满是条件分支的代码，要求用开闭原则重构。比如一个计算工资的方法内部堆满了对正式员工、临时员工和外包员工的条件判断，每新增一种员工类型就要修改这个方法。重构方案是把员工类型抽象成接口，每种类型实现自己的工资计算策略，新增类型时只需要新增一个实现类。
抽象是开闭原则落地的核心手段。你需要预测系统中哪些维度是未来的变化方向，并在这些维度上提前铺设抽象层。如果预测错了，提前铺设的抽象反而变成了不必要的复杂性。你不必为所有变化预留扩展点，但必须为核心业务的变化方向预留扩展点。
实现开闭原则不只有抽象接口一种手法。参数化是更轻量的方式，把变化的部分抽取为方法的参数，配置数据驱动行为变化。回调机制让调用方注入行为片段，插入点逻辑不改动框架代码。元数据驱动把变化规则外置到配置文件或数据库中，业务逻辑变更时只改配置不改代码。软考选择题中，命题人可能会把其中某一种描述成唯一正确的方式，你需要识别出这几种都是开闭原则的不同风格实现。
里氏替换原则在所有 SOLID 原则中最为严格，因为它不是建议而是强制性约束。用通俗的话说：只要父类出现的地方，替换成子类之后程序的行为应该保持不变。
保持行为不变是一个极其苛刻的要求。子类在覆盖父类方法时，不能强化前置条件，不能弱化后置条件，不能改变父类方法承诺的不变性约束。前置条件指方法执行前必须满足的状态要求，子类不能要求调用方提供比父类更严格的条件。后置条件指方法执行后保证达成的结果，子类必须至少满足父类承诺的所有结果。
软考中关于里氏替换的考察集中在反例识别上。最经典的反例是正方形继承自矩形。数学上正方形是矩形，但在面向对象的继承语义中，正方形不能继承矩形。因为矩形有两个独立的宽度和高度属性，分别设置宽度和高度不会互相影响。而正方形的宽度和高度必须保持相等，设置宽度会自动改变高度。当一段代码拿了矩形类型的引用，期望设置宽度后高度保持不变，如果这个引用实际指向一个正方形对象，高度也变了，程序的行为就改变了。这就是典型的违反里氏替换的案例。
里氏替换在工程上的实践意义
本篇完！