13-C#.Net-设计模式六大原则-学习笔记

关注

原创最新推荐文章于 2026-07-07 15:22:43 发布 606 阅读 AI 写同款· GEO 优化 ›

C#知识库：你的“知识管家”有多懂你？ 🔥关注墨瑾轩，带你探索编程的奥秘！🚀🔥超萌技术攻略，轻松晋级编程高手🚀🔥技术宝库已备好，就等你来挖掘🚀🔥订阅墨瑾轩，智趣学习不孤单🚀🔥即刻启航，编程之旅更有趣🚀C#知识库不仅是开发者的技术指南，更是你的“智能助手”——它能像女朋友一样贴心，却又比她更理性、更可靠。阅读详情

六大原则是写出高质量、可维护代码的基础，记住一句话：对修改关闭，对扩展开放是核心思想，其余五条都是在不同角度强化这个目标。

一、SRP — 单一职责原则

Single Responsibility Principle

核心思想

一个类(或方法)只负责一件事，只有一个引起它变化的原因。

通俗理解

厨师只管做菜，服务员只管上菜，收银员只管收钱。如果一个人全干，哪个环节出问题都要改这个人。

代码中的问题演示

// 反例：Animal 类的 Breath() 方法承担了所有动物的呼吸逻辑
public void Breath()
{
    if (_Name.Equals("鸡")) Console.WriteLine("呼吸空气");
    else if (_Name.Equals("鱼")) Console.WriteLine("呼吸水");
    // 每新增一种动物就要改这个方法 —— 违反SRP
}

正确做法：拆分成多个类

// 抽象基类定义职责
public abstract class AbstractAnimal
{
    protected string _Name;
    public abstract void Breath();  // 呼吸是谁的职责？各自子类的
    public abstract void Action();  // 行动是谁的职责？各自子类的
}

public class Chicken : AbstractAnimal
{
    public override void Breath() => Console.WriteLine($"{_Name} 呼吸空气");
    public override void Action() => Console.WriteLine($"{_Name} flying");
}

public class Fish : AbstractAnimal
{
    public override void Breath() => Console.WriteLine($"{_Name} 呼吸水");
    public override void Action() => Console.WriteLine($"{_Name} swimming");
}

实际案例：BankClient 拆分

以银行客户端为例，一个典型的违反 SRP 的写法是把所有逻辑堆在一个类里：

// 反例：所有职责混在一起
public class BankClient
{
    public void Run()
    {
        // 1. 验证用户
        // 2. 查询余额
        // 3. 计算利息
        // 4. 展示结果
        // 任何一个环节变化，都要改这个类
    }
}

正确做法是按变化原因拆分：

public class UserCheckService  { public bool CheckUser(string id) { ... } }
public class AccountService    { public decimal GetBalance(string id) { ... } }
public class InterestCalculator{ public decimal Calculate(decimal balance) { ... } }
public class DisplayService    { public void Show(decimal amount) { ... } }

验证逻辑可能从数据库换成远程接口，余额查询可能换数据源——变化原因不同，就该分开。

记忆口诀

一个类，一件事，改一处，不牵连。

二、OCP — 开闭原则

Open Closed Principle

核心思想

对扩展开放，对修改关闭。新增功能时，尽量不改已有代码，而是新增代码。

通俗理解

手机出了新功能，不是把旧手机拆了重装，而是出一款新型号。

四种扩展方式

以 Student.Study() 方法为例，当需要新增"免费学习"功能时，有四种做法，优劣各不同：

方式1：直接改原方法(最差)

public virtual void Study(bool isFree = false)
{
    if (isFree) Console.WriteLine("Study Free");
    else Console.WriteLine("Study Paid");
    // 改了原有逻辑，可能引入新 Bug，影响已有功能
}

方式2：在原类新增方法(次之)

public class Student
{
    public virtual void Study() => Console.WriteLine("Study Paid");
    public virtual void StudyFree() => Console.WriteLine("Study Free"); // 新增，不改原方法
}
// 缺点：原类仍然被修改，随着功能增多类会越来越臃肿

方式3：继承扩展(推荐)

public class StudentChild : Student
{
    public override void Study()
    {
        base.Study();
        Console.WriteLine("Study Review"); // 扩展行为
        // 完全不修改父类，通过继承扩展
    }
}

方式4：新增独立类(最彻底)

public class StudentFree  // 全新的类，完全不影响原有 Student
{
    public virtual void Study() => Console.WriteLine("Study Free");
}

记忆口诀

加功能，加代码；别动旧代码。

三、LSP — 里氏替换原则

Liskov Substitution Principle

核心思想

子类必须能够替换父类使用，且程序行为不变。换句话说：能用父类的地方，换成子类也没问题。

通俗理解

你叫了一辆出租车，来了一辆网约车，你还是能到达目的地——这就是替换。但如果来了一辆自行车，你就到不了——这就违反了替换原则。

C# 中的多态机制

理解 LSP 的关键是搞清楚 C# 里三种方法的行为差异：

// 父类引用指向子类对象
ParentClass instance = new ChildClass();

instance.CommonMethod();   // 调用的是父类的 CommonMethod(new 隐藏，不是多态)
instance.VirtualMethod();  // 调用的是子类的 VirtualMethod(override 覆写，多态生效)
instance.AbstractMethod(); // 调用的是子类的 AbstractMethod(抽象方法必须覆写)

三种方法的区别：

方法类型	关键字	子类能否覆写	父类引用调用结果
普通方法	无	用 `new` 隐藏	调用父类版本
虚方法	`virtual`	用 `override`	调用子类版本(多态)
抽象方法	`abstract`	必须 `override`	调用子类版本(多态)

什么时候不该继承？

继承要满足"is-a"关系。如果子类无法完整履行父类的所有契约，就不该继承。

以 People 和 Japanese 为例：假设 People 有一个 Traditional() 方法(传统礼仪)，而 Japanese 的礼仪体系完全不同，强行继承后要么抛异常，要么调用方需要做类型判断——这就违反了 LSP。

// 违反LSP的写法
public class Japanese : People
{
    public override void Traditional()
    {
        throw new NotImplementedException(); // 被迫实现，但实际不支持
    }
}

// 正确：断掉不合适的继承关系，各自独立
public class Japanese
{
    public void Ninja() { ... }  // 只实现自己真正有的行为
}

判断是否该继承的简单方法： 把子类替换到所有使用父类的地方，程序行为是否仍然正确？如果不是，就不该继承。

记忆口诀

子类替父类，行为不能变；不是"是一种"，就别乱继承。

四、ISP — 接口隔离原则

Interface Segregation Principle

核心思想

不要让一个类被迫实现它用不到的接口方法。接口要小而专，不要大而全。

通俗理解

你去餐厅只想点菜，不需要同时学会做菜、洗碗、收银。如果菜单上把这些都列出来要求你会，那就太荒谬了。

反例：大而全的接口

// 问题接口：包含了所有功能
public interface IExtendAll
{
    void Photo();   // 拍照
    void Online();  // 上网
    void Game();    // 游戏
    void Record();  // 录像
    void Movie();   // 看电影
    void Map();     // 地图
    void Pay();     // 支付
}

TV 类实现 IExtendAll 的问题：

public class TV : IExtendAll
{
    public void Online() { ... }  // 电视能上网 ✓
    public void Movie() { ... }   // 电视能看电影 ✓
    public void Photo() { throw new NotImplementedException(); }  // 电视不能拍照！被迫实现 ✗
    public void Pay()   { throw new NotImplementedException(); }  // 电视不能支付！被迫实现 ✗
}

正确做法：拆分成小接口

public interface IExtendPhoto  { void Photo(); }
public interface IExtendRecord { void Record(); }
public interface IExtendGame   { void Online(); void Game(); }

// 相机只实现它需要的接口
public class Camera : IExtendPhoto, IExtendRecord
{
    public void Photo()  { ... }
    public void Record() { ... }
    // 不需要实现 Online/Game/Pay 等
}

// 需要组合时，通过接口继承
public interface IExtendAll2 : IExtendPhoto, IExtendRecord, IExtendGame
{
    void Movie(); void Map(); void Pay();
}

ISP vs SRP 的区别

SRP 说的是类只做一件事
ISP 说的是接口只暴露需要的方法

记忆口诀

接口要小，按需实现；大接口拆小，各取所需。

五、DIP — 依赖倒置原则

Dependence Inversion Principle

核心思想

高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

通俗理解

你用充电器充电，插头是标准接口(抽象)，不管是苹果还是安卓的充电器(具体实现)，只要符合接口标准就能用。你不需要为每种手机买专用充电器。

反例：依赖具体类

public class Student
{
    // 每新增一款手机，就要在 Student 里加一个方法 —— 高层依赖低层
    public void PlayiPhone(iPhone phone) { phone.Call(); phone.Text(); }
    public void PlayLumia(Lumia phone)   { phone.Call(); phone.Text(); }
    public void PlayMi(Mi phone)         { phone.Call(); phone.Text(); }
    // 来了 Honor 怎么办？再加一个 PlayHonor？
}

正确做法：依赖抽象

// 抽象层
public abstract class AbstractPhone
{
    public abstract void Call();
    public abstract void Text();
}

// 高层模块依赖抽象，不依赖具体
public class Student
{
    public void PlayPhone(AbstractPhone phone)  // 参数是抽象类
    {
        phone.Call();
        phone.Text();
    }
}

// 新增手机只需新增类，Student 完全不用改
public class Honor : AbstractPhone
{
    public override void Call() { ... }
    public override void Text() { ... }
}

抽象类 vs 接口

DIP 中的"抽象"可以用抽象类或接口来实现，两者各有适用场景：

// 用接口实现 DIP
public interface IPhotoInterface
{
    void Photo();
    void Video();
}

// 高层只依赖接口，不关心具体实现
IPhotoInterface photo = new iPad();
photo.Photo();
photo.Video();
// 想换成其他设备？只需注入不同的实现类，上层代码不用改

抽象类和接口的选择：

抽象类：有公共实现逻辑可以共享时用(比如多个手机品牌都有相同的 Show() 展示逻辑，放在抽象基类里共享)
接口：纯约束，没有实现，多继承场景用(C# 不支持多继承，但支持实现多个接口)

记忆口诀

依赖抽象不依赖具体；新增功能加类，不改旧代码。

六、LOD — 迪米特法则

Law Of Demeter(也叫最少知识原则)

核心思想

一个对象应该对其他对象保持最少的了解。只和"直接朋友"说话，不和"陌生人"说话。

直接朋友指：当前对象本身、方法参数、方法返回值、成员变量。

通俗理解

你找工作，只需要联系 HR，不需要直接联系每个部门负责人。HR 帮你协调，你不需要了解公司内部结构。

反例：School 直接操作 Student

// 违反迪米特：School 直接操作 Student(陌生人)
public void ManageOther()
{
    foreach (Class c in ClassList)
    {
        // School 直接拿到 StudentList，直接操作 Student
        List<Student> studentList = c.StudentList;
        foreach (Student s in studentList)
        {
            Console.WriteLine(s.StudentName);  // School 不应该直接认识 Student
        }
    }
}

正确做法：通过直接朋友委托

// 遵循迪米特：School 只和 Class 说话
public void Manage()
{
    foreach (Class c in ClassList)
    {
        c.ManageClass();  // School 只调用 Class 的方法，不直接碰 Student
    }
}

// Class 负责管理自己的 Student
public void ManageClass()
{
    foreach (Student s in StudentList)
    {
        s.ManageStudent();  // Class 才是 Student 的直接朋友
    }
}

访问修饰符与迪米特

访问修饰符本质上也是迪米特法则的体现——控制"谁能知道什么"：

private：只有自己知道(隐私)
protected：只有子类知道
internal：只有同一程序集知道
public：所有人都知道

暴露越少，耦合越低。 设计类时，默认从 private 开始，只在真正需要时才提升可见性。

记忆口诀

只和朋友说话，不认识的别搭理；中间人帮你传话，自己别乱串门。

六大原则总结对比

原则	英文缩写	一句话总结
单一职责	SRP	一个类只做一件事
开闭原则	OCP	扩展加代码，修改不动旧代码
里氏替换	LSP	子类能无缝替换父类
接口隔离	ISP	接口要小而专，不强迫实现无用方法
依赖倒置	DIP	依赖抽象，不依赖具体实现
迪米特法则	LOD	只和直接朋友交互，降低耦合