写在前面
一直想抽出一些时间来写一写博客，最近准备重拾那份决心，但是仔细思考了下却不知何入手。思来想去，觉得还是以设计模式为契机，可以很好的对自己的学习进行相应的总结，接下来的文章中，会有参考其他资料的部分，在此提醒一下，请各位同学理解。
学习思路
参考哲学三大问题：
- 我是谁？
- 我从哪里来？
- 我要到哪里去？
当然，我们不会对各个设计模式问人类的问题，那么我们也带着三个问题去学习设计模式及其他的知识点：
- 他是谁？
- 他能干什么？
- 他怎么使用？
接下来关于设计模式的总结，我将以这样的思路进行相关的表述，除此之外，也会对一些内容进行补充讲解，如有疑问及异议，请于博客下留言，我将与您共同探讨，我相信讨论会使两个人都有收益的！
设计原则1： 单一职责原则SRP
1、SRP是谁？
单一职责原则，简称SRP（Single responsibility principle），从其中文含义，我们就可以理解其所要表达的思想：职责（也就是功能）单一！
备注一下： 其出自 罗伯特·C·马丁（Robert C. Martin）的《敏捷软件开发：原则、模式和实践》一书。
2、SRP能干什么？
SRP所要表述的思想是职责单一，那么也就是说一个类（或方法）不需要负责太多的职责，其只需要负责自己应该负责的某一职责即可！举个通俗的例子，以软件开发人员为例：后端软件开发人员只需要负责功能需求的开发即可，其不应该去进行UI和测试的工作（这里在现实中好像不可能）。
从上述例子可以看出：在现实中，很少有完全符合SRP的情况，包括在实际的软件开发中，如果某个类仅仅只负责一个职责，那似乎程序代码是如此的不可想象。
在SRP的思想基础上，我们应该要考虑的点不能完全限定于SRP的理论，我们需要注意以下几点：
- 1、在定义对象职责时，需要充分考虑职责与对象之间的关系；
- 2、职责需要很好的体现出对象的行为方式
3、SRP怎么使用？
3.1 不符合SRP的示例
来看下老师Teacher这个类，现在很多的高校老师一方面教书育人，另一方面处理党政事务，这其实是两种行为，但是在本例中均为教师担任，这是不符合SRP的原则的。
package top.flygrk.ishare.srp;
/**
* @Classname: Teacher
* @Description: 不符合SRP原则的示例
* @Date: 2019/8/1 23:57
* @Created by: flygrk
*/
public class Teacher {
public void teachStudent() {
System.out.println("老师教学生知识~");
}
public void handlePartyAffairs() {
System.out.println("处理党政事务~");
}
}
3.2 符合SRP原则的示例
以上述不符合SRP的原则的示例来修改，使其符合SRP原则，其实这很简单，在建立类别时，我们让教师只负责教书育人这种行为，将处理党政事务这种行为交由党员类别即可。
- Teacher：
package top.flygrk.ishare.srp.accord;
/**
* @Classname: Teacher
* @Description: 符合SRP原则的示例
* @Date: 2019/8/2 0:08
* @Created by: flygrk
*/
public class Teacher {
public void teachStudent() {
System.out.println("老师教学生知识~");
}
}
- PartyMember：
package top.flygrk.ishare.srp.accord;
/**
* @Classname: PartyMember
* @Description: 符合SRP的示例
* @Date: 2019/8/2 0:09
* @Created by: flygrk
*/
public class PartyMember {
public void handlePartyAffairs() {
System.out.println("处理党政事务~");
}
}
从上述示例也能看出，严格遵循单一职责原则SRP之后，各个类只负责单一的职责，类结构清晰。但是也存在一定的弊端。下面我们来总结一下其优缺点。
4、SRP的优点
- 1、类的复杂性降低，实现什么职责都有清晰明确的含义；
- 2、可读性提高
- 3、可维护性提高
- 4、变更代码引起的风险降低。如果接口的单一职责做的好，一个接口的修改只对相应的实现类有影响，对其他接口没有影响。
5、SRP的缺点
我们也可以认为其没有较为明显的缺点吧，在实际应用中，只是比较难以完全遵循SRP。
建议： 开发中，接口开发必须遵循SRP原则，类开发尽量遵循SRP原则。
补充点：
关于SRP的内容基本上就总结完毕了，关于SRP的知识点，需要在实践中进行体验。下面补充一些知识点内容：
- 违反SRP的设计模式： 外观模式Facade、代理模式Proxy
