SOLID 原则：让代码更易维护

SOLID 原则：让代码更易维护

SOLID 是面向对象设计中的五项基本原则。它的目标不是让代码看起来更复杂，而是降低模块之间的依赖，让代码更容易理解、修改、测试和扩展。

S：单一职责原则

Single Responsibility Principle，SRP

一个类只负责一类事情，并且最好只有一个引起它变化的原因。

例如，订单服务不应该同时负责订单计算、数据库保存和邮件通知。可以将这些职责分别交给：

• OrderCalculator：计算订单金额
• OrderRepository：保存订单
• EmailService：发送通知

这样修改邮件功能时，就不会影响订单计算逻辑。

一个类做好一件事。

O：开闭原则

Open/Closed Principle，OCP

软件应该对扩展开放，对修改关闭。

例如，系统支持微信支付后，又要增加支付宝支付。更合理的方式是定义统一接口：

public interface IPayment
{
    void Pay(decimal amount);
}

不同支付方式分别实现该接口。增加新支付方式时，只需添加新实现，不必修改已有支付逻辑。

新需求尽量通过扩展实现，而不是反复修改旧代码。

L：里氏替换原则

Liskov Substitution Principle，LSP

子类应该能够替换父类，并且不会破坏程序原有行为。

例如，如果 Bird 定义了 Fly()，企鹅继承 Bird 后却无法飞行，就说明这个继承关系不合理。可以将能力拆分为：

public interface IBird
{
    void Eat();
}

public interface IFlyable
{
    void Fly();
}

企鹅只实现 IBird，会飞的鸟再实现 IFlyable。

子类不仅要符合语法上的继承，还要符合行为上的约定。

I：接口隔离原则

Interface Segregation Principle，ISP

不要让一个类依赖它不需要的方法，应将庞大的接口拆分成多个小接口。

例如，不要定义一个包含打印、扫描和传真功能的大接口，让普通打印机被迫实现它不支持的功能。可以拆分为：

public interface IPrinter
{
    void Print();
}

public interface IScanner
{
    void Scan();
}

public interface IFax
{
    void Fax();
}

不同设备只实现自己需要的接口。

接口应该小而专一，使用者只依赖自己需要的能力。

D：依赖倒置原则

Dependency Inversion Principle，DIP

高层业务不应该直接依赖底层实现，二者都应该依赖抽象。

例如，订单服务不应直接创建具体的邮件服务：

var emailService = new EmailService();

而应依赖通知接口：

public class OrderService(INotificationService notificationService)
{
    public void Submit()
    {
        notificationService.Send("订单提交成功");
    }
}

这样可以随时将邮件通知替换为短信、站内消息，也便于在单元测试中使用模拟实现。

依赖接口，而不是依赖具体类。

总结

SOLID 可以简单概括为：

原则	核心思想
单一职责	一个类只做好一类事情
开闭原则	通过扩展支持变化
里氏替换	子类能够可靠地替代父类
接口隔离	不依赖不需要的方法
依赖倒置	面向抽象编程

SOLID 不是必须机械遵守的规则，而是一组设计指导。当代码开始难以修改、难以测试，或者修改一个功能会影响许多无关模块时，可以用这些原则重新审视设计。