单一职责就是指一个类应该专注于做一件事。现实生活中也存在诸如此类的问题：“一个人可能身兼数职，甚至于这些职责彼此关系不大，那么他可能无法做好所有职责内的事情，所以，还是专人专管比较好。”我们在设计类的时候，就应该遵循这个单一职责原则。
记得有人比喻过软件开发、设计原则、设计模式之间的关系就是战争、战略和战术的关系，关于设计模式实际上是设计原则的具体应用，以后我们还会讲到这一点。另外，大家都很熟悉计算器的例子，很多的人都愿意以此为例，我们也以计算器编程为例说明单一职责原则：
在有些人眼里，计算器就是一件东西，是一个整体，所以它把这个需求进行了抽象，最终设计为一个Calculator类，代码如下：
class Calculator{
public String calculate() {
Console.Write("Please input the first number:");
String strNum1 = Console.ReadLine();
Console.Write(Please input the operator:");
String strOpr= Console.ReadLine();
Console.Write("Please input the second number:");
String strNum2 = Console.ReadLine();
String strResult = "";
if (strOpr == "+"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));
}
else if (strOpr == "-"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.ToDouble(strNum2));
}
else if (strOpr == "*"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));
}
else if (strOpr == "/"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));
}
Console.WriteLine("The result is " + strResult);
}
}
另外，还有一部分人认为：计算器是一个外壳和一个处理器的组合。
class Appearance{
public int displayInput(String &strNum1,String &strOpr, String &strNum2) {
Console.Write("Please input the first number:");
strNum1 = Console.ReadLine();
Console.Write(Please input the operator:");
strOpr= Console.ReadLine();
Console.Write("Please input the second number:");
strNum2 = Console.ReadLine();
return 0;
}
public String displayOutput(String strResult) {
Console.WriteLine("The result is " + strResult);
}
}
class Processor{
public String calculate(String strNum1,String strOpr, String strNum2){
String strResult = "";
if (strOpr == "+"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) + Convert.ToDouble(strNum2));
}
else if (strOpr == "-"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) - Convert.ToDouble(strNum2));
}
else if (strOpr == "*"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) * Convert.ToDouble(strNum2));
}
else if (strOpr == "/"){
strResult = Convert.ToString(Convert.ToDouble(strNum1) / Convert.ToDouble(strNum2));
}
return strResult;
}
}
为什么这么做呢？因为外壳和处理器是两个职责，是两件事情，而且都是很容易发生需求变动的因素，所以把它们放到一个类中，违背了单一职责原则。
比如，用户可能对计算器提出以下要求：
第一，目前已经实现了“加法”、“减法”、“乘法”和“除法”，以后还可能出现“乘方”、“开方”等很多运算。
第二，现在人机界面太简单了，还可能做个Windows计算器风格的界面或者Mac计算器风格的界面。
所以，把一个类Calculator 拆分为两个类Appearance和Processor，一个类做一件事情，这样更容易应对需求变化。如果界面需要修改，那么就去修改Appearance类；如果处理器需要修改，那么就去修改Processor类。
我们再举一个邮件的例子。我们平常收到的邮件内容，看起来是一封信，实际上内部有两部分组成：邮件头和邮件体。电子邮件的编码要求符合RFC822标准。
第一种设计方式是这样：
interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(String content);
}
class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(String content) {// set content; }
}
这个设计是有问题的，因为邮件头和邮件体都有变化的可能性。
1、邮件头的每一个域的编码，可能是BASE64，也可能是QP，而且域的数量也不固定。
2、邮件体中封装的邮件内容可能是PlainText类型,也可能是HTML类型，甚至于流媒体。
所谓第一种设计方式违背了单一职责原则，里面封装了两种可能引起变化的原因。
我们依照单一职责原则，对其进行改进后，变为第二种设计方式：
interface IEmail {
public void setSender(String sender);
public void setReceiver(String receiver);
public void setContent(IContent content);
}
interface IContent {
public String getAsString();
}
class Email implements IEmail {
public void setSender(String sender) {// set sender; }
public void setReceiver(String receiver) {// set receiver; }
public void setContent(IContent content) {// set content; }
}
有的资料把单一职责解释为：“仅有一个引起它变化的原因”。这个解释跟“专注于做一件事”是等价的。如果一个类同时做两件事情，那么这两件事情都有可能引起它的变化。同样的道理，如果仅有一个引起它变化的原因，那么这个类也就只能做一件事情。
单一职责原则的使用
单一职责原则的尺度如何掌握？我们怎么能知道该拆分还是不应该拆分呢？原则很简单：需求决定。如果你所需要的计算器，永远都没有外观和处理器变动的可能性，那么就应该把它抽象为一个整体的计算器；如果你所需要的计算器，外壳和处理器都有可能发生变动，那么就必须把它拆离为外壳和处理器。
单一职责原则实际上是把相同的职责进行了聚合，避免把相同的职责分散到不同的类之中，这样就可以控制变化，把变化限制在一个地方，防止因为一个地方的变动，引起更多地方的变动的“涟漪效应”，单一职责原则避免一个类承担过多的职责。单一职责原则不是说一个类就只有一个方法，而是具有单一功能。
我们在使用单一职责原则的时候，牢记以下几点：
A、一个设计合理的类，应该仅有一个可以引起它变化的原因，即单一职责，如果有多个原因可以引起它的变化，就必须进行分离；
B、在没有需求变化征兆的情况下，应用单一职责原则或其他原则是不明智的，因为这样会使系统变得很复杂，系统将会变成一堆细小的颗粒组成，纯属于没事找抽；
C、在需求能够预计或实际发生变化时，就应该使用单一职责原则来重构代码，有经验的设计师、架构师对可能出现的需求变化很敏感，设计上就会具有一定的前瞻性。
