软件设计六大原则

1、单一职责原则（Single Responsibility Principle，SRP）：应该有且仅有一个原因引起类的变更。（接口、类、方法均适用） 
单一职责原则的好处：
类的复杂性降低，实现什么职责都有清晰明确的定义；
可读性提高；
可维护性提高； 
引起的风险降低，一个接口修改只对相应的实现类有影响，对其他的接口无影响。
    单一职责原则最难划分的就是职责，一个职责一个接口，但是问题是“职责”是一个没有量化的标准，一个类到底要负责那些职责？这些职责怎么细化？细化后是否都要有一个接口或类？

生搬硬套单一职责原则会引起类的剧增，给维护带来麻烦；过分的细分类的职责也会人为的制造系统的复杂性。
2、里氏替换原则（Liskov Substitution Principle）：所有引用基类的地方必须能透明地使用其子类的对象。 

里氏替换原则包含四层意思：

子类必须完全的实现父类的方法。 
子类可以有自己的个性。  
覆盖或实现父类的方法时输入参数可以被放大。  
覆盖或实现父类的方法是输出结果可以被缩小。  
3、依赖倒置原则（Dependence Inversion Principle）：高层模块不应该依赖于底层模块，两者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖抽象。  

面向接口编程，减少类之间的耦合性，并行开发。
4 、接口隔离原则（Interface Segregation Principle）：类间的依赖关系应该建立在最小的接口上。  

接口隔离原则是对接口进行规范约束，其包含以下四层含义：
接口尽量要小。根据接口隔离原则拆分接口时，必须首先满足单一职责原则。 
接口要高内聚。具体到接口隔离原则就是要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
定制服务。
接口设计是有限度的。一个接口只服务于一个子模块或者业务逻辑。 通过业务逻辑压缩接口中的public方法。已经被污染了的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。了解环境，拒绝盲从。
5、迪米特法则(Low Of Demeter) ，也称最少知识原则（Least Knowledge Principle）：一个类对自己需要耦合或者调用的类应该知道的最少。 
   尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private,package-private、protected等访问权限。核心观念就是类间解耦，弱耦合。
6、开闭原则（Open Close Principle）：一个软件实体应该对扩展开放，对修改关闭。  

抽象约束。通过接口或抽象类可以约束一组行为，并且能够实现扩展开放，其包含三层含义：一是通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；二是在参数类型定义、输入输出参数尽量使用接口或者抽象类，而不是实现类，三是抽象层尽量保持稳定，一旦确定即不允许修改。

封装变化。对变化的封装包含两层含义：一是对相同的变化封装到一个接口或抽象类中，二是对不同的变化封装到不同的接口或抽象类中，不应该出现两个不同的变化出现同一个接口或抽象类中。封装变化，准确的讲就是封装可能发生的变化。