定义：
 
 
 
对类来说的，即一个类应该只负责一项职责。
 
 
问题由来：
 
类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，，由于类T承担的职责有多个（p1,p2），职责P1的变化有可能会导致原本运行正常的职责P2功能发生故障。
 
以交通工具案例讲解，我们有交通工具摩托车、汽车、飞机供我们选择。
 
package com.dongguo.principle.singleresponsibility1;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-18:17
 * @description:交通工具类
 */
class Vehicle {
    /**
     * @author Dongguo 
     * @description: 摩托车汽车在公路上运行，飞机在天上飞
     */
    public void run(String vehicle) {
        System.out.println(vehicle + " 在公路上运行....");
    }
}
 
package com.dongguo.principle.singleresponsibility1;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-18:15
 * @description:单一职责原则
 */
public class SingleResponsibility {
    public static void main(String[] args) {

        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.run("飞机");
    }
}
运行结果：
摩托车 在公路上运行....
汽车 在公路上运行....
飞机 在公路上运行....
 
在交通工具类Vehicle的run 方法中，违反了单一职责原则，不可能所有的交通工具都可以在公路上运行，摩托车汽车在公路上运行，而飞机应该在天上飞
 
解决方案：
 
遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
 
根据交通工具运行方法不同，分解成不同类即可，即将交通工具类Vehicle分解成陆上交通工具RoadVehicle、天上交通工具AirVehicle
 
package com.dongguo.principle.singleresponsibility2;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-19:27
 * @description: 陆上交通工具
 */
public class RoadVehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "公路运行");
    }
}
 
package com.dongguo.principle.singleresponsibility2;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-19:27
 * @description: 天上交通工具
 */
public class AirVehicle {
    public void run(String vehicle) {
        System.out.println(vehicle + "天空运行");
    }
}
 
package com.dongguo.principle.singleresponsibility2;


/**
 * @author Dongguo
 * @date 2021/8/21 0021-19:27
 * @description:
 */
public class SingleResponsibility {
    public static void main(String[] args) {
        RoadVehicle roadVehicle = new RoadVehicle();
        roadVehicle.run("摩托车");
        roadVehicle.run("汽车");
        AirVehicle airVehicle = new AirVehicle();
        airVehicle.run("飞机");
    }
}
运行结果：
摩托车公路运行
汽车公路运行
飞机天空运行
 
我们发现这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。
 
如果直接修改Vehicle 类，改动的代码会比较少
 
 
妥协示例（项目中常见的单一职责违背可接受示例）
 
说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。
 
所谓职责扩散，就是因为某种原因，职责Ｐ被分化为粒度更细的职责Ｐ１和Ｐ２.
 
比如：类T只负责一个职责P，这样设计是符合单一职责原则的。后来由于某种原因，也许是需求变更了，也许是程序的设计者境界提高了，需要将职责P细分为粒度更细的职责P1，P2，这时如果要使程序遵循单一职责原则，需要将类T也分解为两个类T1和T2，分别负责P1、P2两个职责。但是在程序已经写好的情况下，这样做简直太费时间了。所以，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样做有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为我们不会想到这个职责P，在未来可能会扩散为P1，P2，P3，P4……Pn。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。）
 
package com.dongguo.principle.singleresponsibility3;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-19:40
 * @description: 这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责
 */
public class Vehicle {
    
    public void run(String vehicle) {
        System.out.println(vehicle + " 在公路上运行....");
    }

    public void runAir(String vehicle) {
        System.out.println(vehicle + " 在天空上运行....");
    }
}
 
 
package com.dongguo.principle.singleresponsibility3;

/**
 * @author Dongguo
 * @date 2021/8/21 0021-19:40
 * @description:
 */
public class SingleResponsibility {
    public static void main(String[] args) {
        Vehicle vehicle = new Vehicle();
        vehicle.run("摩托车");
        vehicle.run("汽车");
        vehicle.runAir("飞机");
    }
}
运行结果：
摩托车 在公路上运行....
汽车 在公路上运行....
飞机 在天空上运行....
 
 
可以看出，这种修改没有改动原来的方法，而是在类中添加了一个方法，这样虽然也违背了单一职责原则，但在方法级别上却是符合单一职责原则的，因为它并没有改动原来方法的代码。
 
遵循单一职责的好处：
 
可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
提高类的可读性，提高系统的可维护性；
变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，对其他功能无影响，这对系统的扩展性，维护性都有非常大的帮助
通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则：只有类中方法足够少，可以在方法级别保持单一职责原则。
 
例如本文所举的这个例子，它太简单，它只有一个方法，所以，无论在代码还是在方法级别违背单一职责原则，都不会造成太大的影响。　实际应用中的类都要复杂的多，一旦发生职责扩散而需要修改类时，除非这个类本身非常简单，否则还是要遵循单一职责原则。
 
难点：
 
职责划分无量化标准
单一职责妥协：项目中是很难完美的体现单一职责的，由于项目的开发环境，工作量，开发人员的技术水平等因素，往往会违背单一职责的原则
单一职责只是提出了一个编写程序的标准，可以用是否遵循单一职责来衡量接口或类的设计是否优良话，但是单一职责原则最难划分的就是职责，职责没有一个量化的标准，一个类到底负责哪些职责，这些职责该如何细化，都要从实际的项目去考虑，所以应因项目而异，因环境而异。
 
 
单一职责与接口隔离的区别：
 
单一职责原则注重的是职责；而接口隔离原则注重对接口依赖的隔离。
单一职责原则主要是约束类，其次才是接口和方法，它针对的是程序中的实现和细节； 而接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。
 
 

单一职责原则 【Single Responsibility Principle】
 
  定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
 问题由来：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
 
  解决方案：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
 
  说到单一职责原则，很多人都会不屑一顾。因为它太简单了。稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。
 
  举例说明：只要做过项目，肯定要接触到用户、机构、角色管理这个模块，我们今天要讲的是用户管理，管理用户的信息，增加机构（一个人属于多个机构），增加角色等，用户有这么的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看类图：
 
   太easy的类图了，我相信即使一个初级的程序员也可以看出这个接口设计的有问题，用户的属性（Properties）和用户的行为（Behavior）没有分开，这是一个严重的错误！非常正确，确实是这个接口设计的一团糟，应该把用户的信息抽取成一个业务对象（BussinessObject，简称B0），把行为抽取成另外一个接口中，我们把这个类图重新画一下：
 

   这个类图看起来完全满足了类和接口的单一职责要求，非常符合标准，但是我相信你在设计的时候肯定不会采用这种方式，一个用户类要把把两个IUserB0和IUserBiz组合在一块才能使用，组合是一种强耦合关系，你和我都是有共同的生命期，这样的强耦合关系还不如使用接口实现的方式呢，而且还增加了类的复杂性，多了两个类呀，我们修改一下类图：
   重新拆封成两个接口，IUserB0负责用户的属性，简单的说就是IUserB0的职责是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户的信息的维护和变更。各位可能要问了，这个和我实际的工作中用到的User类还是有差别的呀，别着急，我们先来想一想分拆成两个接口怎么使用，想清楚了，我们看是面向的接口编程，所有呀你产生了这个UserInfo对象之后，你当然可以把它当IUserB0接口使用，当然也可以当IUserBiz接口使用，这要看你在怎么地方使用了，你要获得用户想信息，你就当时IUserB0的实现类；你要是想维护用户的信息，就当是IUserBiz的实现类就成了，类似于如下代码：
 
IUserBiz userInfo=new UserInfo();
//我要赋值了，我就认为它是一个纯粹的
BO IUserBO userB0=(IUserBO）userInfo；
userBO.setPassword("abc");
//我要执行动作了，我就认为是一个业务逻辑类
IUserBiz userBiz=(IUserBiz)userInfo；
userBiz.deleteUser();
 
  这样的设计，一个用户实现了两个接口，把两个职责融合一个类中，你会觉得这个UserInfo有两个原因引起变化了呀，是的是的，但是别忘记了我们是面向接口编程，我们对外公布的是接口而不是实现类；而且如果真要实现类的单一职责的话，这个就必须使用了上面组合的方式了，那这个会引起类间耦合过重的问题（我们等会再说明这个问题，继续往下看）。那使用了单一职责原则有什么好处呢？
 
  单一职责使用于接口、类，同时也使用方法，什么意思呢？一个方法尽可能做一件事情，比如一个方法修改用户密码，别把这个方法放到“修改用户信息”方法中，这个方法的颗粒度很粗，比如这个一个方法：
 
 
  在IUserManager中定义了一个方法叫changeuser，根据传递的type不同，把可变长度参数changeOptions修改到userBo这个对象上，并调用持久层的方法保存到数据库中。
 这种方式要简单的多。但是却存在着隐患：每次新增、移除某个type都需要对原有代码进行修改啊；进而可能影响到其他type的操作，这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但方法职责不清晰，不单一，隐患却是最大的。一般方法设计成这样的：
 
 
  你要修改用户名称，就调用changeUserNane方法，你要修改家庭地址就调用changellomeAddress，你要修改单位单户就调用changeofficeTel方法，每个方法的职责就非常清晰，这也是一个良好的设计习惯。
 
  对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了，考虑项目环境，考虑工作量，考虑人员的技术水平，考虑硬件的资源情况等等，最终融合的结果是经常违背这一单一原则。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦；而且过分的细分类的职责也为人为的制造系统的负责性，本来一个类可以实现的行为非要拆成两个，然后使用聚合或组合的方式再耦合在一起，这个是人为制造了系统的复杂性，所以原则是死的，人是活的，这句话是非常好的。但是我相信随着技术的深入，单一职责原则必然会深入到项目的设计中去，而且这个原则是那么的简单，简单的我都不知道该怎么更加详细的去描述，单从字面上大家都应该知道是什么意思，单一职责嘛！
 
  遵循单一职责原的优点有：
   可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
   提高类的可读性，提高系统的可维护性；
   变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
   需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。

接口隔离原则和单一职责原则区别
 
单一职责原则是备受争议的原则，根据不同的业务逻辑，它会将系统功能模块划分成不同种类，产生多样的接口，同时每个接口尽量只包含一个功能（方法）。
 
而产生争议的原因就是这个业务逻辑的概念太过于模糊，同时它与接口隔离原则又似乎有些冲突。
 
接口隔离原则，是指一个类对另一个类的依赖应该建立在最小的接口上。
 
通过定义我们可以得知，单一职责原则注重的是职责的划分，而接口隔离原则注重的是类对接口的依赖的隔离。两个定义站在的角度是不同的，就像不同的两个对象，站在的角度不同，所划分的角度就有所不同。
 
同时单一职责原则是直接在业务方面划分，所以是站在接口的角度上观看来约束类，业务逻辑首先应该考虑大的模块，这个大的模块就应该是最顶层的抽象类或接口，所以是站在接口的角度上来看；而接口隔离原则定义说的是“一个类对另一个类的依赖”，这个定义是类与类直接的，所以接口隔离原则应该是站在类的角度上来约束接口。
 
单一职责原则与接口隔离原则之间还是有共同点的：
 
单一职责原则与接口隔离原则最终表现出来的都是将接口约束到最小功能，所以在这个表现结果层面来看二者都是将接口可以被实现的方法变得越来越小。
 
所以我们定义接口时应该从两个方面来考虑。
 
首先是业务逻辑层面，要先将业务划分好，所需要的每个模块的功能进行划分，尽量划分到一个功能模块仅有一个方法。
 
其次我们在定义类的时候也要再次考虑接口的定义是否有冗余，是否有可以再度拆分的可能，功能可否达到更简等。
 
通过两个层面的考虑，我们就可以最终敲定上层接口了。
 
以上内容仅为个人对接口隔离原则和单一职责原则的理解，如有漏洞欢迎指教。

简介
 
本文我们将讨论面向对象编程中著名的 SOLID 原则之一的单一职责原则。我们将深入讲解什么是单一职责原则和在设计代码时如何实现它，最后将如何避免滥用此设计规则。单一职责的英文表达为 Single Responsibility Principle ，简称 SRP。
 
单一职责原则详解
 
就像它的名字的字面意思一样，这个原则表示每个类应该只有一个职责，也就是只有一个目的，一个类只做一样工作，以此可以推断出这个类只有一个原因被修改。我们不想让对象知道的太多以及承担与自己无关的职责，否则，这些类很难维护，例如，一个类由于不同的原因被修改，这个类应该根据职责被拆分为多个类，每个类符合单一职责原则。这样，当错误发生时，可以很容易的找到发生错误的地方。
 
下面一个类负责用不同的方法来修改文本信息，修改文本信息是它唯一的职责。
 
public class TextManipulator {
    private String text;
 
    public TextManipulator(String text) {
        this.text = text;
    }
 
    public String getText() {
        return text;
    }
 
    public void appendText(String newText) {
        text = text.concat(newText);
    }
    
    public String findWordAndReplace(String word, String replacementWord) {
        if (text.contains(word)) {
            text = text.replace(word, replacementWord);
        }
        return text;
    }
    
    public String findWordAndDelete(String word) {
        if (text.contains(word)) {
            text = text.replace(word, "");
        }
        return text;
    }
 
    public void printText() {
        System.out.println(textManipulator.getText());
    }
}
 
虽然这个类看上去没问题，但是对于 SRP 来说，不是一个好的例子，它承担了两个职责，维护和打印文本。
 方法 printText 违反了单一职责原则，为了符合此原则，我们需要另外一个类专门用来打印文本，代码如下：
 
public class TextPrinter {
    TextManipulator textManipulator;
 
    public TextPrinter(TextManipulator textManipulator) {
        this.textManipulator = textManipulator;
    }
 
    public void printText() {
        System.out.println(textManipulator.getText());
    }
 
    public void printOutEachWordOfText() {
        System.out.println(Arrays.toString(textManipulator.getText().split(" ")));
    }
 
    public void printRangeOfCharacters(int startingIndex, int endIndex) {
        System.out.println(textManipulator.getText().substring(startingIndex, endIndex));
    }
}
 
类 TextPrinter 专门用来提供各种打印文本的方法，打印是它的唯一职责，符合 SRP。
 
如何避免误用单一职责原则
 
在开发过程中使用 SRP 的技巧是理清每个类的职责。然而，每个开发者对每个类的目的都有自己理解，这样增加了使用SRP 的难度，因为没有严格的规则指导我们如何实现 SRP，因此，可能会出现根据每个人不同的理解设计出不同的类实现。这样的实现比较主观，会使实现SRP 比较困难，不像我们上面的例子这么简单。那有没有其他原则来规范我们实现SRP 呢？有的，下面来讲内聚性。
 
内聚性
 
遵循SRP 原则，我们的类将承担单一职责，类的方法和数据都是和这个职责相关联的，这样的设计从内聚性的角度来看是高内聚的，高内聚和健壮性一起来减少我们程序的出错概率。
 当我们的设计基于SRP 时，根本上也符合高内聚特性，高内聚能帮我们为类找到单一职责，反过来，也能帮我们找到某些类承担了过多的职责。
 让我们回到类 TextManipulator 的方法定义：
 
public void appendText(String newText) {
    text = text.concat(newText);
}
 
public String findWordAndReplace(String word, String replacementWord) {
    if (text.contains(word)) {
        text = text.replace(word, replacementWord);
    }
    return text;
}
 
public String findWordAndDelete(String word) {
    if (text.contains(word)) {
        text = text.replace(word, "");
    }
    return text;
}

 
这里，我们对这个类的职责有一个清晰的描述：文本维护。但是，如果我们不考率内聚性和对类的职责有清晰的定义。我们可以对于文本的写和更新 操作放在两个类去实现，比如 WriteText 和 UpdateText。 这样设计的话，事实上，这两个类紧耦合在一起，而且是低内聚，两个类会经常放在一起使用。虽然这三个方法执行不同的操作，但是其目的都是一个：操作文本，这样的话，我们就过度设计了。
 
总结
 
虽然这个设计原则从名字来讲它是自解释的，看起来实现也简单，事实上，正确的实现 SRP不是那么容易 , 我们要仔细从职责的角度设计类而且还要额外的关注类的内聚性。