1.单一职责原则
2.开放-封闭原则
3.依赖倒转原则
4.里氏代换原则
5.接口隔离原则
6.迪米特原则
1.单一职责原则
什么是单一职责原则？
单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则
单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小
通俗一点：
1.就是一个类越复杂，可能被复用的可能性越小
2.类越复杂，变动代码可能会有意想不到的错误。
我认为单一职责的目的其实是为了最大可能的复用。
为什么要复用？举个栗子：
现在有这么一个servlet，它包含了数据库的连接，验证密码是否正确的数据库操作，同时有登录的业务逻辑（当用户名正确时跳转主页，密码失败时跳转登录页面）。
咋一看没什么问题，实现了登录功能。
现在我们要增加一个功能，修改密码，只有当旧的密码正确，才能修改密码。
老办法：把登录的代码（数据库连接，验证密码是否正确的数据库操作）粘贴过来，新写修改密码的业务逻辑（用户名正确则可以修改，否则修改失败）。
其实两个servlet中只有最后一点业务逻辑操作不同。（登录/登录失败）（修改密码成功/修改密码失败）
看起来也不错，也实现了功能。
但是现在需求又更改了：
1.数据库名字更换/连接密码更改，所有servlet的数据库的连接都要修改
2.要求只有启用状态的的账号能够登录，验证密码是否正确的数据库操作也有两个地方要修改
没使用复用的话，一个小改动，所有重复代码都要改动。
对于没有使用复用的代码，维护起来简直就是灾难！
怎么这些代码可以复用起来？
（一个类越复杂，可能被复用的可能性越小）
（一个类越简答，功能越单一，可能被复用的可能性越大）
让他们“单一职责”，功能单一就可以啦
数据库的连接抽象成一个类，负责数据库的连接
数据库操作抽象成一个类，负责对数据操作
servlet中，负责业务逻辑判断。
如果使用复用，仅需要一点简单的修改，全局的代码都能修改。
所以我们设计的类尽可能的职责单一，尽可能的功能单一，这样才能保证我们能够顺利的复用。
为什么系统横向分为dao,service,controller三层，微服务则是纵向的将服务进行切分。
目的：
减少代码的冗余，同时做到易修改。
职责单一，可以复用。