单一职责原则

定义 单一职责原则，就一个类而言，应该仅有一个引起它变化的原因。 应用范围 单一职责原则适用的范围有接口、方法、类。按大家的说法，接口和方法必须保证单一职责，类就不必保证，只要符合业务就行。 方法 设想一下这个场景：假设我们要做一个用户修改名字以及修改密码的功能，可以有多种实现方案，比如下面列举 2 种实现方式 代码： 第一种实现方式 第二种实现方式 2种实现有什么区别呢？ 第一种实现通过 OprType 类型的不同来做不同的事情，把修改密码和修改名字耦合在一起，容易引起问题，只要稍不注意，传错枚举值就悲剧了，在代码中也没法很直接看到是做什么操作，也就是这个方法的职责不明确。而第二种实现，把修改密码和修改名字分离开来，也就是把修改密码和修改名字都当做独自的职责处理，这样子就很清晰明了，你调用哪个方法，就很明确的知道这个方法是实现什么逻辑。结论是啥呢？用第二种方式实习才符合单一职责原则。现实中看到很多像第一种实现的代码，而且是枚举有十来个的情况，看代码真费劲。 好处 类的复杂性降低，实现什么职责都有清晰明确的定义 可读性提高，复杂性降低，那当然可读性提高了 可维护性提高，可读性提高，那当然更容易维护了 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助 总结 这个单一职责原则

设计模式之六大原则（转载） 　　关于设计模式的六大设计原则的资料网上很多，但是很多地方解释地都太过于笼统化，我也找了很多资料来看，发现CSDN上有几篇关于设计模式的六大原则讲述的比较通俗易懂，因此转载过来。 　　原作者博客链接： http://blog.csdn.net/LoveLion/article/category/738450/7 一.单一职责原则 　　原文链接： http://blog.csdn.net/lovelion/article/details/7536542 　　单一职责原则是最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义如下： 单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。 单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。 单一职责原则是实现高内聚、低耦合的指导方针

内聚性： 一个模块的组成元素之间的功能相关性。 就一个类而言，应该仅有一个引起它变化的原因。 当需求变化时，该变化会反映为类的职责的变化，如果一个类承担了多于一个的职责，那么引起它变化的原因就会有多个。 如果一个类承担的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。 这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 什么是职责？ 在SRP中，吧职责定义为“变化的原因”。如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个职责。有时，很难注意到这一点，我们习惯于以组的形式去考虑职责。 Modem接口，大多数人认为这个接口非常合理： public interface Modem { public void dial(String pno); public void hangup(); public void send(char c); public void recv(); } 然而，该接口却显示两个职责（1）连接管理（2）数据通信。 dial和hangup连接处理，send和recv数据通信 这两个职责应该被分开吗？这依赖于应用程序变化的方式。如果应用程序的变化会影响连接函数的签名，那么这个设计就具有僵化性的臭味，因为send和recv的类必须要重新编译。 在这种情况下，这两个职责应该被分离

单一职责是指一个类或者方法出现两种以上职责，一旦需求的变更，这时候要修改一项职责，有可能就会影响到另一个职责。 解决办法： 将两个职责用两个类来实现，进行解耦。 发现： 既然单一职责原则规定我们尽量不要把不同的职责写在同一个方法内，但是java又提供重载这一机制。 public class ICompany { public void create(String branch){ if("人事".equals(branch)){ System.out.println(branch+"招人"); }else System.out.println(branch+"推市场"); } } public static void main(String[] args) { ICompany iCourse=new ICompany(); iCourse.create("人事"); iCourse.create("销售"); } 下面把两个职责分别写两个类实现 public class ICompanyHr { public void create(String branch){ System.out.println("招聘"); } } public class ICompanySell { public void craete(String branch){ System.out

单一职责原则（ Single Responsibility Principle ） 定义： 不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。 问题由来： 类 T 负责两个不同的职责：职责 P1 ，职责 P2 。当由于职责 P1 需求发生改变而需要修改类 T 时，有可能会导致原本运行正常的职责 P2 功能发生故障。 解决方案： 遵循单一职责原则。分别建立两个类 T1 、 T2 ，使 T1 完成职责 P1 功能， T2 完成职责 P2 功能。这样，当修改类 T1 时，不会使职责 P2 发生故障风险；同理，当修改 T2 时，也不会使职责 P1 发生故障风险。 说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。 所谓职责扩散，就是因为某种原因，职责 P 被分化为粒度更细的职责 P1 和 P2 。 比如：类 T 只负责一个职责 P ，这样设计是符合单一职责原则的。后来由于某种原因