软件设计的六大原则

目录

一、单一职责原则（SRP: Single responsibility principle）

二、开放封闭原则（OCP: Open Closed Principle）

三、里氏替换原则  ( LSP: Liskov Substitution Principle)

四、接口隔离原则（ ISP: Interface Segregation Principle）

五、依赖倒置原则（ DIP: Dependence Inversion Principle）

六、迪米特原则（Law of Demeter）

---

一、单一职责原则（SRP: Single responsibility principle）

一个软件系统的最佳结构高度依赖于开发这个系统的组织的内部结构。这样，每个软件模块都有且只有一个需要被改变的理由;

一个模块应该只服务于同一类客户，而不是多种客户。例如：有一个工资计算类，在初期由于公司不同部门之间的工资计算方式是一样的。把这个工资计算类用于计算所有部门的工资，将来公司的技术部工资计算方式变了，而其它部门保持不变。就有可能因为修改了这个工资计算类而影响了其它部门的工资计算。应该为不同的客户创建不同的类。

一个函数应该只提供一种功能，不能创建多功能的函数。例如：一个计算函数既可以计算加法又可以计算减法。

二、开放封闭原则（OCP: Open Closed Principle）

如果软件系统想要更容易被改变，那么其设计就必须允许增加新的代码来修改系统的行为，而非只能靠修改原来的代码。

也就是说一个类在写完之后就不应该再发生改变（本身业务发生改变和改bug除外）。如果有新的功能加进来，应该可以通过增加新的类来实现。例如：我要实现 “加减乘除” 计算。如果只是简单的写一个类，里面包含“加减乘除”四个函数。这个时候如果需要增加“取余”计算的话，就需要在原来的类上增加“取余”函数。这就违反了开放封闭原则。我们应该创建一个接口，里面包含一个计算函数；然后编写“加减乘除”四个类来实现接口。这样当有“取余”计算方式加进来的时候只需要创建一个新类来实现这个接口就可以了。

三、里氏替换原则  ( LSP: Liskov Substitution Principle)

如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换；

也就是说子类可以替换父类，且不会对业务产生任何影响。例如父类ParentA 有两个函数Method1 和Method2，子类ChildA继承自父类ParentA且实现了父类的Method1 和Method2函数。而子类ChildB继承自父类ParentA，但是只实现了父类的Method1；这个时候原先的代码是ParentA p = new ChildA();是没有问题的，但是将ChildB替换掉ChildA就可能发生问题了。因为ChildB没有去实现Method2函数；

ChildB中的Method2可能是个空函数；public override void Method2(){}

四、接口隔离原则（ ISP: Interface Segregation Principle）

这项设计原则主要告诫软件设计师应该在设计中避免不必要的依赖。

一个类应该尽量少的把自己的信息透露给客户。应该采用接口的方式来隔离不同的功能函数。例如：ClassA中有20个函数，但是对于同一类客户B只需要用到其中的5个函数，那么应该采用接口Interface的方式来定义这五个函数，让ClassA实现这个接口。这样对于客户B来说就只能看到自己所需要的函数。

五、依赖倒置原则（ DIP: Dependence Inversion Principle）

该设计原则指出高层策略性的代码不应该依赖实现底层细节的代码，两者都应该依赖抽象。

抽象工厂设计模式就是该设计原则最好的实践。使用抽象工厂类来向客户提供相应的功能。当需求发生改变的时候，只需要增加相应的具体实现代码， 并修改抽象工厂类就可以了， 无需更改客户端和原有的具体实现类的代码。

六、迪米特原则（Law of Demeter）

又叫做最少知道原则，如果两个类不必彼此直接通信，那么这两个类就不应当直接调用，可以使用代理的方式通过第三方来转发调用。

一个对象应该对其它对象尽可能的少知道，或者说被引用的对象应该尽量不要把别人不需要的成员暴露出去。这就可以降低类与类之间的耦合度。类之间的耦合度越低就越有利于复用。