构建健壮的代码.md

本章节主要讲述代码设计中的常用规范。

单一职责原则

SRP:Single Responsibility Principle，单一职责原则

类应只描述一件事情，方法应只做一件事。在实际开发中类肯能会违背单一职责原则，但方法要严格遵守单一职责原则。

如果引起类发生变化的原因超过一个，那么就有可能违背了单一职责原则。

如果不能用一句话来描述类或方法的作用，那么它很有可能就不符合单一职责原则。

类只应在其所表述的内容发生改变时而变化，不应因外界发生变化而变化。

单一职责保证了高内聚，利于测试。

开闭原则

OCP:OpenClosedPrinciple，开闭原则

对扩展开放对修改关闭，即，在尽可能不修改原有代码的情况下新增或改变原有功能。各种框架，如：ASP.NET Core中的各种扩展点既是如此。

在维护系统时，开闭原则可以降低整体风险，因为原有逻辑未被改变。

里氏替换原则

LSP:Liskov Substitution Principle，里氏替换原则

换句话说就是：父类出现的地方子类均可以出现，且不会造成负面影响。即，使用者不用关心，也无需知道这里出现的是父类还是子类。也可以理解为接口类型有着不同的实现类。

里氏替换原则会使得客户端代码变得简单，可以参考【错误和异常】——>【错误编号，异常与返回Null的替代方案】——>【针对特殊情况的设计】一节。

接口隔离原则

ISP:Interface Segregation Principle，接口隔离原则

与单一职责原则类似，强调的是接口职能单一，即接口粒度尽量细化，而不是使用大而全的一个接口。从另一个角度来说，一个大而全的接口中会包含实现类并不关心的内容。举例如下：

public interface IDemo
{
    void A();
    void B();
}

public class AImp : IDemo
{
    public void A()
    {
        // ...
    }

    // B方法所表述的内容在该类中并不关心
    public void B()
    {
        throw new NotImplementedException();
    }
}

如上述代码，客户端在调用时会遇到问题：

IDemo demo = new AImp();
// 抛出 NotImplementedException 异常
demo.B();

KISS原则

KISS:Keep It Simple Stupid，保持简单与愚蠢

代码设计尽可能保持简单，不要因过度追求性能二丧失可读性，也不要过度设计。

时刻想下别人在首次阅读自己的代码时会不会遇到困惑。或者，一个水平一般的程序员处于线上宕机情况下去阅读你的代码以寻找引发宕机事故的压力之下，是否可以较为容易读懂你的代码。

避免重复代码

DRY:Don’t Repeat Yourself，不要重复

系统中，重复代码越多，越难以维护，这点想必大家都有所体会。

DRY原则也可用于配置文件，集群环境下使用统一配置中心来管理配置信息，而不是每台服务器上均存放配置文件。

YAGNI

YAGNI:You Aren’t Gonna Need It，你不需要它

一句话说明：不要编写自己感觉将来可能会用到的代码，不要过度设计。

尽可能不要存在当前未用到的代码，因为：

• 未用到的代码也需要测试与维护，导致成本的增加；

• 会让后来维护代码的人疑惑；

• 将来可能用到的时候，业务需求或许已经发生了变化；

参考【注释】——>【五种应该避免的注释】——>【注释掉的代码】

小结

所有的设计准则都一个共同的目标：高内聚、低耦合。

我们在编码时也应有一个基本目标：可读性好、易于测试和维护。

最后多说一句，抽象思维很重要。

推荐阅读

《设计模式之禅》（第二版）