六大原则是设计模式的基石, 是后面所提具体的二十三种设计模式的指导思想

总则: 开放封闭原则

对扩展开放, 对修改封闭

当我们需要添加新的功能时, 可以通过添加新的代码或者模块来实现, 而不需要修改已有的功能模块, 这样可以避免新增的功能影响到原来已经在正常运行的功能

最简单的例子就是函数重载

public void Add(int i)
{
    this.List.Add(i.ToString("N"));
}
public void Add(string i)
{
    this.List.Add(i);
}
public void Add(DateTime time)
{
    this.List.Add(time.ToString("yyyy-MM-dd HH:mm:ss.fff"));
}

当我们需要Add一个新的类型时, 只需要添加一个重载函数即可, 不需要修改已有的Add函数

以下算是一个反例

public void Add(object obj)
{
    if (obj is int i)
        this.List.Add(i.ToString("N"));
    else if (obj is string str)
        this.List.Add(str);
    else if (obj is DateTime time)
        this.List.Add(time.ToString("yyyy-MM-dd HH:mm:ss.fff"));
}

单一职责原则

一个类或者一个方法只有一个职责, 只做一件事情, 只处理一个业务

该原则要求尽可能降低类或方法的复杂度, 提高可读性

下面先来一个简单的反例

public void SetUser(string name, int age, DateTime birthday)
{
    this.name = name;
    this.age = age;
    this.birthday = birthday;
}

假设类中有一个用于设置用户信息的SetUser方法, 可以通过传入三个参数设置三个字段的值

此时这个函数拥有三个职责, 设置name 设置age 设置birthday

如果我想要单独设置其中的某一个字段, 在现在这种情况下我需要先获取另外两个字段的值, 然后一起传给这个函数

这在使用的时候就非常不方便, 我们可以根据这三个职责将函数进行拆分

public void InitUser(string name, int age, DateTime birthday)
{
    this.name = name;
    this.age = age;
    this.birthday = birthday;
}
public void SetName(string name)
{
    this.name = name;
}
public void SetAge(int age)
{
    this.age = age;
}
public void SetBirthday(DateTime birthday)
{
    this.birthday = birthday;
}

将原来的SetUser改为InitUser, 意为初始化用户信息, 这时候才需要传全部的三个参数

新增了 SetName SetAge SetBirthday三个函数, 分别对应 设置name 设置age 设置birthday这三个职责

里氏替换原则

子类可以替换父类, 并保持父类的功能和特性, 父类可以出现的地方, 都可以使用其子类进行代替

简单来说就是子类的行为应当尽量与父类保持一致

下面来一个简单的反面例子

public class User
{
    protected string name;
    public virtual void SetName(string name)
    {
        this.name = name;
    }
}
public class Student: User
{
    public override void SetName(string name)
    {
    }
}

子类Student重写了SetName方法, 但是这个重写的方法并不会对name字段进行修改, 这无疑就违反了SetName方法的本意, 会让其他人在使用这个方法时会不小心掉进坑里

public class User
{
    protected string name;
    public virtual void SetName(string name)
    {
        this.name = name;
    }
}
public class Student: User
{
    public override void SetName(string name)
    {
        this.name = name;
    }
}

一般来说正常实现这个方法即可

依赖倒置原则

高层模块不应该依赖于低层模块, 二者都应该依赖于抽象, 而不是具体的实现细节

public class Apple
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class Pineapple
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class Pen
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class PenPineappleApplePen
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class User
{
    private List<Apple> Apples { get; set; }
    private List<Pineapple> Pineapples { get; set; }
    private List<Pen> Pens { get; set; }
    private List<PenPineappleApplePen> PenPineappleApplePens { get; set; }

    public void AddApple(Apple good)
    {
        Apples.Add(good);
    }
    public void AddPineapple(Pineapple good)
    {
        Pineapples.Add(good);
    }
    public void AddPen(Pen good)
    {
        Pens.Add(good);
    }
    public void AddPenPineappleApplePen(PenPineappleApplePen good)
    {
        PenPineappleApplePens.Add(good);
    }

    public decimal Count()
    {
        decimal sum = 0;
        sum += Apples.Sum(item => item.Price);
        sum += Pineapples.Sum(item => item.Price);
        sum += Pens.Sum(item => item.Price);
        sum += PenPineappleApplePens.Sum(item => item.Price);
        return sum;
    }
}

上面的User可以购买四种商品, 每种商品都可以添加多个, 加完之后还可以结算价格

但每增加一种商品, User类就需要进行一次修改, 这无疑是非常麻烦且违反开闭原则的

所以我们可以简单地修改一下

public abstract class Good
{
    public string Name { get; set; }
    public decimal Price { get; set; }
}
public class Apple: Good
{
}
public class Pineapple: Good
{
}
public class Pen: Good
{
}
public class PenPineappleApplePen: Good
{
}
public class User
{
    private List<Good> Goods { get; set; }

    public void AddGood(Good good)
    {
        Goods.Add(good);
    }

    public decimal Count()
    {
        decimal sum = Goods.Sum(item => item.Price);
        return sum;
    }
}

让User不再依赖具体的商品, 而是依赖抽象的Good, 这样即使具体的商品实现部分有增减修改, 只要抽象的Good没有变化, 就不需要修改现有的模块

接口隔离原则

尽量使用多个专门的接口, 而不是单一的总接口

有时候我们会设计一个"大而全"的接口, 能做很多事情

public interface ICrud<T>
{
    T Get(object id);
    T[] GetList(Condition input);
    void Add(T input);
    void Update(T input);
    void Delete(object id);
}

比如以上的ICrud接口就定义了增删查改总共5个方法, 实现这个接口时需要将这五个方法都实现一遍

但有些情况下我们可能只需要使用查询功能, 这时候就要额外写用不到的三个实现, 会使类变得臃肿, 并且可能会产生副作用

此时就可以考虑按照读写或者增删查改拆分接口, 下面就简单拆分一下

public interface IRead<T>
{
    T Get(object id);
    T[] GetList(Condition input);
}
public interface IWrite<T>
{
    void Add(T input);
    void Update(T input);
    void Delete(object id);
}
public interface ICrud<T>: IRead<T>, IWrite<T>
{
}

拆分之后的ICrud不受影响, 多出来IRead和IWrite对应读写, 在只读的情况下我们可以只实现IRead

如果有需要, 可以再根据增删查改进行接口拆分

最少知道原则

一个对象应该对其他对象有尽可能少的了解, 不应该直接与其他对象发生联系

这样做的目的是降低类之间的依赖, 降低耦合, 从而使各个功能模块尽可能独立

public class Teacher
{
    public void GetStudentInfo(Student stu)
    {
        string info = $"学生名称: {stu.Name}; 年龄: {stu.Age}";
    }
}

public class Student
{
    public string Name { get; set; }
    public int Age { get; set; }
}

以上的Teacher在GetStudentInfo中尝试获取学生信息拼接而成的字符串, 此时Teacher类对Student类的细节知道的就太多了, 如果Student中添加了新的属性, Teacher中就需要针对这个新加的属性做对应修改, 然而这些新加的属性可能与Teacher本身并没有什么关联, 也不是Teacher需要关心的, 这种高耦合设计会在日后带来很多麻烦

所以我们需要将这些细节屏蔽掉

public class Teacher
{
    public void GetStudentInfo(Student stu)
    {
        string info = stu.GetInfo();
    }
}

public class Student
{
    public string Name { get; set; }
    public int Age { get; set; }
    public DateTime Birthday { get; set; }
    public bool Gender { get; set; }
    public string GetInfo()
    {
        return $"学生名称: {Name}; 年龄: {Age}; 生日: {Birthday.ToString("yyyy-MM-dd")}; 性别: {(Gender ? "男" : "女" )}";
    }
}

像这样把具体的拼接过程放到Student中去实现, 尽可能让Student的更改只局限在Student中, 不影响其公开暴露出来的部分, 只要GetInfo这样的业务没有发生变化, Teacher就不需要进行修改

合成复用原则

尽量使用合成, 而不是通过继承达到复用的目的

程序员对于"复用"是有执念的, 一般来说不喜欢把同一个功能写两遍, 复用代码最简单的方式是 ctrl + c ctrl + v, 这种方式虽然简单, 但是也有很多隐患, 比如无法统一修改

另一种比较简单直接的方式是继承, 继承一个现有的类即可获得这个类的功能

public class Gun
{
    public string ProductNo { get; set; }
    public void Shoot()
    {
        Console.WriteLine("啪");
    }
}
public class Police: Gun
{
}

Police通过继承Gun可以复用Shoot方法, 但是与此同时也继承了ProductNo生产批次号, 从业务上来说, Police与生产批次号应该是完全没有关系的, 又不是机械战警

所以这里通过继承来复用就非常不合适了

public class Gun
{
    public string ProductNo { get; set; }
    public void Shoot()
    {
        Console.WriteLine("啪");
    }
}
public class Police
{
    private Gun gun;
    public Police(Gun gun)
    {
        this.gun = gun;
    }
    public void Shoot()
    {
        gun.Shoot();
    }
}

通过组合进行复用可能是一种更合适的方式