标签：职责 软件开发 分离 原则 耦合 SRP 详解 敏捷 变化

一、单一原则（SRP）

　　就一个类而言，应该仅有一个引起他变化的原因。

　　如果一个类承担的职责过多，就等于把这些职责耦合在了一起。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的（ fragile）设计，当变化发生时，设计会遭到意想不到的破坏。
二、什么是职责？

　　在SRP 中,我们把职责定义为“变化的原因”（a reason for change)。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于–个的职责。有时，我们很难注意到这一点。我们习惯于以组的形式去考虑职责。如果应用程序的变化会影响连接函数的签名(signature)，那么这个设计就具有僵化性；另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们。实际上,分离它们就会具有不必要的复杂性。在此还有–个推论。变化的轴线仅当变化实际发生时才具有真正的意义。如果没有征兆,那么去应用SRP，或者任何其他原则都是不明智的。
三、分离耦合的职责
　　常常会有·些和硬件或者操作系统的细节有关的原因，迫使我们把不愿耦合在·起的东西耦合在了-起。然而，对于应用的其余部分来说，通过分离它们的接口我们已经解耦了概念。
四、持久化
　测试驱动的开发实践常常会远在设计出现问题之前就迫使我们分离这两个职责。然而，在测试不能迫使职责分离的情况下，僵化性和脆弱性会变得很强烈，那么就应该使用FACADE 或者PROXY模式对设计进行重构，分离这两个职责。
五、结论
　　SRP是所有原则中最简单的之一，也是最难正确运用的之一。我们会自然地把职责结合在一起。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。事实上，我们将要论述的其余原则都会以这样或那样的方式回到这个问题上。

标签：职责,软件开发,分离,原则,耦合,SRP,详解,敏捷,变化
来源： https://www.cnblogs.com/cvnewfish/p/16185114.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。