设计模式-单一职责原则（设计模式开篇）

开篇

作为设计模式的开篇，首先对设计模式需要有一定认识。
百度百科中对于设计模式的解释：设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。
个人理解：设计模式就是在众多软件开发人员面临一般性问题时的解决方案，而这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。

为什么学习设计模式

在工作中有一个很深刻的体会就是需求总是不断变化的。如果新增一个需求，作为开发人员都想很简单高效地去实现，甚至最理性的是只需要改动一下配置文件或一处代码即可。但是由于整个系统在最初设计时考虑不够周全，导致了开发人员修改一处代码可能会影响到其它的代码，或许开发人员修改了N处代码实现了需求，随着需求不断变化，整个系统会变得越来越臃肿，代码难以维护，甚至失控。

简单认识单一责任原则

单一责任原则：单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。
核心思想：一个类或接口在设计时，它的职责只有一个，修改这个类或接口时的原因只有一个，就是它的职责有一定变化。职责过多，引起变化的原因就会越多。也就是说在设计类或接口时，它的职责不应该多于一个。

单一责任原则示例

示例1：

package com.jinit.design.test1;

import java.util.Scanner;

public class Calculator {
	
	public int add(){
		Scanner sc = new Scanner(System.in); 
		int a = sc.nextInt();
		int b = sc.nextInt();
		return a+b;
	}
	
	public static void main(String[] args) {
		 Calculator calculator = new Calculator();
		 System.out.println("计算结果："+calculator.add());
	}
}

我们可以分析出：这个类的负责有从键盘输入中拿到两个数据，然后做加法运算。
这个类就拥有了两个职责：1.获取数据 2.计算数据。引起变化的原因就有两个，就不违背了单一职责原则。
设计不足：

1. 需求变更：任何一个职责变化都会造成类的变化；
2. 新需求：如果添加减法运算，也需要先获取数据，然后计算数据，造成代码重复。

---

示例1改造：
针对获取数据的职责：

package com.jinit.design.test1;

import java.util.Scanner;

public class Loader {
	public int a;
	public int b;
	
	public Loader(){
		Scanner sc = new Scanner(System.in); 
		this.a = sc.nextInt();
		this.b = sc.nextInt();
	}

	public int getA() {
		return a;
	}

	public int getB() {
		return b;
	}
	
}

针对计算数据的职责：

package com.jinit.design.test1;

public class Calculator {
	
	public int add(int a, int b){
		return a+b;
	}
	
	public static void main(String[] args) {
		 Loader loader = new Loader();
		 Calculator calculator = new Calculator();
		 System.out.println("计算结果："+calculator.add(loader.getA(),loader.getB()));
	}
}

我们改造后可以看出Loader类只有获取数据的职责，Calculator类的职责为计算数据。不管需求变更还是新需求，一个引起变化的原因就对应着一个类。
单一职责的好处：

• 类的复杂性降低了
• 可读性提高了
• 可维护性提高了
• 变更引起的风险降低

实际开发中运用情况

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”或“变化原因”都是不可度量的，因项目而已，因环境而已。

总结

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
在实际运用中只能尽量去遵守原则，不一定要强制去满足，就像数据库设计中存在的逆范式。
最后的建议是：对于单一责任原则，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。