一个类只负责一个职责
使用单一职责原则的好处：
1.可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2.提高类的可读性，提高系统的可维护性；
3.变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。
２.依赖倒置原则(DIP)：原始定义：
１高层模块不该依赖于底层模块，它们都该依赖于抽象
２抽象不依靠于细节，细节应该依赖于抽象
备注：抽象指的是接口或者抽象类，细节指的是具体的类。依赖一词是对于多个事务而言的，可以理解为依靠
举个例子说明什么叫做依赖：对象A通过调用对象B的方法或者函数，这就可以理解为A依赖于B，因为A只有“依靠”B才能实现某些功能，又如抽象类A中定义了一些公开的方法，类B实现或者继承A中的某些方法，对A的细节进行了完善，那么B就依赖于A的，因为B的基本功能框架是通过继承或者实现A的方法才能实现的
所以一般如果没有考虑依赖倒置的设计，对象与对象之间的依赖是一种直接的依赖，这是一种紧耦合的设计，当依赖的一方变化的时候，依赖的一方也需要被迫进行修改
自顶而下的程序设计中，通常会将某个业务逻辑划分为一个模块，而它的实现是通过一些粒度比较小的功能点进行完成，小的功能点又可以由更小的功能实现，在面向对象编程中，每一个都是对象，所以高层模块的功能是通过许多底层模块的功能实现的，高层模块调用底层模块，也就是高层模块依赖于底层模块。由于没有考虑依赖倒置的设计原则，高层和底层直接就是直接依赖，两者之间的产生强耦合，在开发过程中，底层模块是比较细节的，而细节的东西往往就是比较繁琐的，所以底层模块一旦需要变化，由于高层模块是直接依赖于底层模块，那么高层模块必须跟着变，而开闭原则要求的是程序对修改关闭，对扩展开放。而且频繁的修改高层模块代码，也会很容易引入错误。所以为了解决这个问题，可以对于具体的实现类加上抽象，它们之间的依赖关系不通过具体的实现类，而是抽象之间的依赖，这样的话，字节的类需要变化，不影响高层模块的使用，因为对于高层的模块（或者原来的依赖方）来说，它看到的只是抽象，具体的实现细节是把看不到的。而抽象的比较稳定，不会发生变化，所以高层的模块不需要改变
依赖导致的核心是其面向接口编程，总结其有以下原则：
１尽量不要用直接依赖，而是通过抽象进行依赖，即每个类最好有抽象
２依赖关系的对象引用变量用的抽象的类型
３任何类不要从具体的类派生
４不要重写基类的方法
３.里氏替换原则(SLP)：所有基类出现的地方都可以派生类替换而不会让程序产生错误，派生类可以扩展基类的功能，但不能改变基类原有的功能
４.开放封闭原则(OCP)：对扩展开放，对修改关闭，一个类独立之后就不应该去修改它，而是以扩展的方式适应新需求
５.接口隔离原则(ISP):客户端不应该强迫依赖它不需要的接口，一个接口应该拥有尽可能少的行为，使其精简单一。对于不同的功能的模块分别使用不同的接口，而不是使用同一个通用接口
6.迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。
