单一职责原则
单一职责原则（Single Responsibility Principle），简称SRP。
其实在日常生活中，单一职责是随处可见的。
- 数码相机的拍照功能
- 音响放歌
在贴近一些我们程序猿生活的
- 做显示处理的显卡
- 做声音处理的声卡
从以上几点出发。可以看出，每个人或者物品分别处理着一个功能，并且在处理自己的领域时，都有着顶级的能力。
- 我们知道，对于数码相机的拍照功能和音响放歌的功能，我们日常生活中的手机都具备着他们两个的能力。但在单独一个能力表现上都不如它们。
手机并不能拍出数码相机的清晰度，也不能放出与音响的3D效果。所以对于数码相机音响来说，单一的功能才可以有更强的实力。 - 同理，cpu 也有集成的显卡和声卡，但是为了用到看到更好的画质，我们增加了显卡。为了更好的音效增加了声卡。显卡声卡在仅有的功能上体现了更强大的实力。
这就是我们要了解的单一职责原则
为什么使用
在开发中我们也需要经常使用到单一职责原则，为了以后更好的维护以及扩展。
如果一个类承担的责任过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离
那么我们什么时候才需要使用呢？
如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责就一个类而言，应该仅有一个引起它变化的原因。
应用场景
对于我们经常使用的工具类，如 Json 解析工具类，http 请求工具类，加密解密工具类。
我们都可以将它们看作单一职责。
我们不要误解 http 请求有 post 请求和 get 请求等。
它拥有多个职责或者说功能。这样的错误理解是把功能看的细节化。
我们必须站在对应的高度来看待某一个类的功能。不可高也不可低。
例如开发中的 DAO 层。
我们可以说增删改查的每个方法都是单一职责。
也可以说一个类处理所有的表的增删该查。这个类的单一职责就是处理数据库表的操作。
应该合理的分解为，一个表一个类。这个类就是处理这个表的单一职责。也是我们开发生涯中常用的。
在日常开发中，我们经常操作的就是 service 服务层。
而服务层的单一职责的设计起到整个项目维护的难易程度，也是最难分离职责的地方。
我们开发时经常把很多功能放在一个 service 里面。导致修改一个功能会左找右找，或者改很多地方。
所以高度的定位是我们未来要通过不断实践来决定的。
单一职责原则在生活中无处不在。
若博客中有错误或者说的不好，请勿介意，仅代表个人想法。
csdn博客：https://blog.csdn.net/LNView
本文地址：https://blog.csdn.net/LNView/article/details/79735095
有问题或者喜欢的欢迎评论。
转载请注明出处！！！！！！
参考资料
《大话设计模式》