## 一句话结论
五项 OOP 设计原则 SOLID，旨在降低代码耦合、提升系统扩展性与长期可维护性。

## 体系讲解
### 原理：SOLID 诞生价值
项目迭代膨胀后，无规范的面向对象代码会形成「大泥球」：一处改动牵连锁多Bug、新增需求要大面积修改旧代码、单元测试难以编写。
SOLID 由 Robert C. Martin 整理，是一套可落地的代码设计评判标准，规避代码腐化，降低维护成本。

### 五大原则速查表
| 原则 | 核心意图 | 典型违规特征 |
| ---- | -------- | ------------ |
| SRP 单一职责 | 一个类仅有一个变更原因，只负责一件事 | 万能上帝类：同时处理数据库、业务、邮件、日志 |
| OCP 开闭原则 | 对扩展开放，对已有稳定代码修改关闭 | 新增业务分支不断修改原有if/switch判断 |
| LSP 里氏替换 | 子类可完全替换父类，不破坏上层逻辑契约 | 子类重写方法抛出父类无声明异常、缩小参数范围、改变返回语义 |
| ISP 接口隔离 | 拆分细粒度专用接口，不强制实现无用方法 | 实现类大量空方法、抛 `not implemented` 异常 |
| DIP 依赖倒置 | 高层、低层模块均依赖抽象，不依赖具体实例 | 构造函数内部 `new` 底层实体类，无法替换实现、难以Mock测试 |

### 各原则解决的核心问题
1. SRP + ISP：优化代码可读性，边界清晰，修改互不干扰；
2. OCP：提升业务扩展性，新增需求不改动已上线测试完成的旧代码；
3. LSP：保障多态调用安全，父子类行为统一；
4. DIP：降低耦合、提升单元测试便利性，是OCP落地的基础。

## 考察意图
1. 能够区分五条原则的适用场景，精准定位代码违反的设计规范；
2. 理解原则背后工程目的，不只会背诵定义；
3. 具备工程权衡思维，明白SOLID是指导标准而非硬性教条，拒绝过度设计。

## 追问链（面试标准问答）
### 1. SRP 单一职责违规案例及重构思路？
简答：`UserService` 同时实现用户查询、注册邮件发送、操作日志写入，存在三类变更理由。
重构拆分：`UserRepository`（数据查询）、`UserNotify`（消息通知）、`UserLog`（日志记录），每个类仅承担单一业务行为。
判断标准：类若需要因两个完全无关的业务场景修改，即违反SRP。

### 2. 符合OCP的支付模块代码架构？
简答：定义统一支付抽象接口 `PaymentInterface`，支付宝、微信、Stripe各自独立实现接口。订单服务仅依赖抽象接口，新增支付渠道只需要新建实现类，原有订单逻辑无需修改。
违规特征：新增支付类型就要在原有代码增加if判断分支。

### 3. 哪些行为会违反LSP里氏替换原则？
简答三类典型违规：
1. 子类抛出父类未声明的异常；
2. 缩小入参前置条件（父类接收所有数字，子类仅允许正数）；
3. 改变返回值语义（父类保证非空返回，子类可能返回null）；
经典反例：矩形父类、正方形子类，正方形修改宽度同步修改高度，破坏父类宽高独立的行为约定。

### 4. 如何判断接口需要拆分（ISP）？
简答：实现类存在无意义空方法、主动抛出未实现异常，代表接口包含该实现不需要的能力，需要拆分为多个细分接口。
例：统一工人接口包含work()、eat()，机器人无需进食，应拆分为 `Workable`、`Feedable`。

### 5. DIP 和其他四条原则的协同关系？
简答：DIP是落地OCP、SRP、ISP的底层基础。
流程链路：SRP拆分单一职责类 → ISP细分抽象接口 → DIP上层依赖抽象、注入底层实现 → OCP新增业务仅新增实现类。无抽象依赖，开闭原则无法落地。

## 高频易错点
1. 误解OCP：认为完全禁止修改所有代码
「对修改关闭」针对经过测试、稳定的抽象层与核心业务代码；修复Bug、早期迭代优化允许修改，不是一刀切禁止改动。

2. 教条化SOLID，过度拆分
极简工具类、仅有一种实现的接口，强行拆分多层抽象会造成过度设计，增加理解成本，原则需结合项目规模取舍。

3. 混淆语法重写与LSP语义约束
PHP语法允许子类重写任意公共、受保护方法，但LSP约束的是**业务行为契约**，不止参数返回值语法兼容，语义不能被破坏。

## 完整代码示例
```php
<?php
// 1. OCP + DIP 标准支付实现
interface PaymentInterface
{
    public function pay(float $amount): bool;
}

// 支付宝实现
class Alipay implements PaymentInterface
{
    public function pay(float $amount): bool
    {
        // 支付宝支付逻辑
        return true;
    }
}

// 微信支付实现
class WechatPay implements PaymentInterface
{
    public function pay(float $amount): bool
    {
        // 微信支付逻辑
        return true;
    }
}

// 订单服务依赖抽象，新增支付渠道无需修改此类
class OrderService
{
    public function __construct(
        private readonly PaymentInterface $payment
    ) {}

public function createOrder(float $total): bool
    {
        return $this->payment->pay($total);
    }
}

// 2. ISP 接口隔离 正反对比
// ❌ 胖接口，违反ISP
// interface Worker
// {
//     public function work(): void;
//     public function eat(): void;
// }

// ✅ 细分小接口，符合ISP
interface Workable
{
    public function work(): void;
}
interface Feedable
{
    public function eat(): void;
}

// 人类同时实现两个接口
class Human implements Workable, Feedable
{
    public function work(): void {}
    public function eat(): void {}
}

// 机器人仅实现工作接口，无冗余空方法
class Robot implements Workable
{
    public function work(): void {}
}
```

已有0条评论

添加新评论☺

如果认为本文对您有所帮助请赞助本站

支付宝扫一扫赞助

已有0条评论

添加新评论☺