开发几大原则理解（单一原则）_关于单一职责原则,以下叙述错误的是( ) a、一个类只负责一个功能领域中的相应职-优快云博客

网上看这张图片归纳挺好的：
这里写图片描述
单一原则(Single Responsibility Principle)
单一职责原则的英文名称是 Single Responsibility Principle，简称是 SPR，简单地说就是一个类只做一件事，这个设计原则备受争议却又极其重要。只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。因为单一职责的划分界限并不是如马路上的行车道那么清晰，很多时候都是需要个人经验来界定。当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。这跟我们社会分工一样，一些人干这个，另一些人干那个，只有大家都这样做了，我们的社会才更和谐。

试想一下，如果你遵守了这个原则，那么你的类就会划分的很细，每个类都有比较单一的职责，这不就是高内聚、低耦合么！当然，如何界定类的职责就需要你的个人经验了。

当然，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离，就是抽象的能力。其实要去判断是否应该分离出类来，也不难，那就是如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

/**
 * @ClassName: OrderSend
 * @Description: 指令发送接口
 * @author: jyj
 * @date: 2017年6月7日 下午10:47:49
 */
public interface OrderSend
{
    String readDeviceName();

    String readDeviceMacAddress();
}

我们可以看到，OrderSend接口中定义了两个方法，分别是读取设备名称和读取设备mac地址。它的职责很单一，这样在需要修改执行指令发送的相关代码时，只需要修改实现 OrderSend接口的类，而不会影响其他类的代码。如果某个类的职责包含有执行指令发送、指令解析等，那么在你修改某处代码时就必须谨慎，以免修改的代码影响了其它的功能。当你修改的代码能够基本上不影响其他功能。这就一定程度上保证了代码的可维护性。注意，单一职责原则并不是一个类只能有一个函数，而是说这个类中的函数所做的工作是高度相关的，也就是高内聚。

基本判断原则，就是一个特定的类，当确认以后，它的责任就确定了，不能增加它行为以外的功能。例如一般我们定义 API 接口的时候，如果这个接口干了很多事情，就是一些隐含的事情，我们就认为它设计没有遵循单一原则。
优点

类的复杂性降低，实现什么职责都有清晰明确的定义。

可读性提高，复杂性降低，那当然可读性提高了。

可维护性提高，可读性提高了，那当然更容易维护了。

变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

下次继续