设计原则

一、单一职责原则：

应该有且仅有一个原因引起类的变更。该原则的好处为：

1.类的复杂性降低，实现什么职责都有清晰明确的定义；

2.可读性提高，复杂性降低，那当然可读性提高了；

3.可维护性提高，可读性提高，那当然更容易维护了；

4.变更引起的风险降低，变更是必不可少的，接口的单一职责做的好的话，一个接口修改只对相应的实现类有影响，与其他的接口无影响，这个是对项目有非常大的帮助。

对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了，生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦；而且过分的细分类的职责也为人为的制造系统的负责性，本来一个类可以实现的行为非要拆成两个，然后使用聚合或组合的方式再耦合在一起，这个是人为制造了系统的复杂性，所以原则是死的，人是活的，这句话是非常好的

 

二、里氏替换法则

只要父类能出现的地方我子类就可以出现，而且调用子类还不产生任何的错误或异常，调用者可能根本就不需要知道是父类还是子类。但是反过来就不成了，有子类出现的地方，父类未必就能适应，里氏替换法则包含了四层意思：

1.子类必须完全的实现父类的方法。

2.子类可以有自己的个性。

3.覆盖或实现父类的方法时输入参数可以被放大。

4.覆盖或实现父类的方法是输出结果可以被缩小。

 

三、依赖倒置原则

 

四、接口隔离原则

建立单一接口，不要建立臃肿庞大的接口。再通俗的一点讲：接口尽量细化，同时接口中的方法尽量的少。看到这里大家有可能要疑惑了，这与单一职责原则不是相同的吗？错，接口隔离原则与单一职责的定义的规则是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，没有要求接口的方法减少，例如一个职责可能包含10 个方法，这10 个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束不使用的方法不要访问，按照单一职责原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”,专门的接口指什么？就是指提供给多个模块的接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，所有的模块可以来访问。

接口隔离原则是对接口进行规范约束，其包含以下四层含义：

1.接口尽量要小。这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface）,但是“小”是有限度的，首先就是不能违反单一职责原则。根据接口隔离原则拆分接口时，必须首先满足单一职责原则。

2.接口要高内聚。什么是高内聚？高内聚就是提高接口、类、模块的处理能力，减少对外的交互。

3.定制服务。一个系统或系统内的模块之间必然会有耦合，有耦合就要相互访问的接口，我们设计时就需要给各个访问者定制服务，我们在做系统设计时也需要考虑对系统之间或模块之间的定义要采用定制服务，采用定制服务就必然有一个要求就是：只提供访问者需要的方法。

4.接口设计是有限度的。接口的设计粒度是越小系统越灵活，这是不争的事实，但是这就带来的结构的复杂化，开发难度增加，维护性降低，这不是一个项目或产品所期望看到的，所有接口设计一定要注意适度，适度的“度”怎么来判断的呢？根据经验和常识判断！

 

五、迪米特法则

迪米特法则也叫做做最少知识原则说的都是一会事，一个对象应该对其他对象有最少的了解，通俗的讲一个类对自己需要耦合或者调用的类应该知道的最少，你类内部是怎么复杂、怎么的纠缠不清都和我没关系，那是你的类内部的事情，我就知道你提供的这么多public 方法，我就调用这个；迪米特法则包含以下四层意思：

1.只和朋友交流：出现在成员变量、方法的输入输出参数中的类被称为成员朋友类。

2.朋友间也是有距离的：迪米特法则就要求类“小气”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private,package-private、protected等访问权限。

3.是自己的就是自己的：在项目中有一些方法，放在本类中也可以，放在其他类中也没有错误，那怎么去衡量呢？你可以坚持这样一个原则：如果一个方法放在本类中，即不增加类间关系，也对本类不产生负面影响，就放置在本类中。

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，你项目管理就复杂，大家在使用的时候做相互权衡吧。

 

六、开闭原则

软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

开闭原则说是对扩展开放，对修改关闭，并不意味着不做任何的修改。