单一职责

单一指责定义：就一个类而言，应该仅有一个引起它变化的原因 ----《大话设计模式》.

通俗来讲，为了降低功能之间的耦合，如果一个类中有多个功能封装在一个方法，如果后期功能升级可能比较困难，所以将类中的方法提取出新类或者新方法进行各自实现完成，后期功能升级或者代码修改，对于其他的功能代码没有太多的影响。
下面举个例子，如果我需要进行
例如我们在一个生物圈中是一个类，类中有鱼和鸟以及人类，每个种类都有自己生活方式，如果将其概括为一个生物圈进行封装实现，那么在修改或者后面种类变多，各个种类生活方式不同，那么后面进行修改也很麻烦，需要修改接口和继承类，每行代码修改都可能影响到其他类功能

/*
	in general
*/
interface biosphere
{
	function walk();
	function fly();
	function swim();

}

class human implements biosphere
{
	/*will error*/
	/*human living style isn't swim and fly*/
}

class fish implements biosphere
{
	/*will error*/
	/*fish can't walk and fly*/
}

class bird implements biosphere
{
	/*will error*/
	/*most bird can't swim*/
}

那么如果使用单一职责来设计，我们可以将每个种类进行划分实现接口类，如果需要增加种类我们只需要再添加一个对应的类即可，不会影响到其他种类的类功能

/*
	SRP
*/
interface bird
{
	function fly();
}

interface fish 
{
	function swim();
}

interface human 
{
	function walk();
}

/*when use the instance you can implements some one*/
class dove implements bird 
{
	public function fly() 
	{
		/*write code here*/
	}
}

/*when use the instance you can implements some one*/
class catfish implements fish 
{
	public function swim() 
	{
		/*write code here*/
	}
}

• 上面的样例我们也可以以生活方式进行划分，如walk为一个接口， swim为一个接口，后面如果新出种类fly我们只需要添加一个即可， 并且在后面的新类中如果有swim&walk的种类出现，我们只需创建一个新类，并继承其对应的接口即可，并不会影响到其他类功能。

写到这里，单一职责我们或许可以理解为一个抽象或者划分不是固定的方式来理解，我们可以按照种类划分，例如bird fish 我们也可以按照walk fly 等进行划分，为的是将多个指责进行抽离各自实现，在后期维护时代价降低，即低耦合，在每个业务场景下会有多个划分场景，多个角度，我们需要通过合适的角度以及后期业务发展进行划分。

博文中也许有不对地方，欢迎指教，每天学一点，每天产出一点~

如果觉得写的不错 欢迎star (●’◡’●) https://github.com/wuye251/design-patterns