设计模式原则（一）--- 单一职责原则

单一职责原则

单一职责原则（Single Responsibility Principle），简称SRP。
其实在日常生活中，单一职责是随处可见的。

• 数码相机的拍照功能
• 音响放歌

在贴近一些我们程序猿生活的

• 做显示处理的显卡
• 做声音处理的声卡

从以上几点出发。可以看出，每个人或者物品分别处理着一个功能，并且在处理自己的领域时，都有着顶级的能力。

• 我们知道，对于数码相机的拍照功能和音响放歌的功能，我们日常生活中的手机都具备着他们两个的能力。但在单独一个能力表现上都不如它们。
  手机并不能拍出数码相机的清晰度，也不能放出与音响的3D效果。所以对于数码相机音响来说，单一的功能才可以有更强的实力。
• 同理，cpu 也有集成的显卡和声卡，但是为了用到看到更好的画质，我们增加了显卡。为了更好的音效增加了声卡。显卡声卡在仅有的功能上体现了更强大的实力。

这就是我们要了解的单一职责原则

为什么使用

在开发中我们也需要经常使用到单一职责原则，为了以后更好的维护以及扩展。
如果一个类承担的责任过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离

那么我们什么时候才需要使用呢？

• 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责
• 就一个类而言，应该仅有一个引起它变化的原因。

应用场景

对于我们经常使用的工具类，如 Json 解析工具类，http 请求工具类，加密解密工具类。

我们都可以将它们看作单一职责。

我们不要误解 http 请求有 post 请求和 get 请求等。
它拥有多个职责或者说功能。这样的错误理解是把功能看的细节化。

我们必须站在对应的高度来看待某一个类的功能。不可高也不可低。

例如开发中的 DAO 层。
我们可以说增删改查的每个方法都是单一职责。
也可以说一个类处理所有的表的增删该查。这个类的单一职责就是处理数据库表的操作。

应该合理的分解为，一个表一个类。这个类就是处理这个表的单一职责。也是我们开发生涯中常用的。

在日常开发中，我们经常操作的就是 service 服务层。
而服务层的单一职责的设计起到整个项目维护的难易程度，也是最难分离职责的地方。
我们开发时经常把很多功能放在一个 service 里面。导致修改一个功能会左找右找，或者改很多地方。

所以高度的定位是我们未来要通过不断实践来决定的。

单一职责原则在生活中无处不在。

---

若博客中有错误或者说的不好，请勿介意，仅代表个人想法。
csdn博客：https://blog.youkuaiyun.com/LNView
本文地址：https://blog.youkuaiyun.com/LNView/article/details/79735095

有问题或者喜欢的欢迎评论。

转载请注明出处！！！！！！

参考资料
《大话设计模式》