设计模式原则篇:(1)单一职责原则--Single Responsibility Princi

????? ? ? ?? 上篇文章提及到设计模式中应遵循的设计原则，并且列出了设计模式中应当遵循的六大原则。

?????? 次篇文章主要讨论单一职责原则。

???????????? 单一职责原则(SRP)：

???????????????????????? 不要存在多于一个导致类变更的原因。简单的讲，就是一个类或接口只负责一个"职责"。

????????????? 如果一个类有一个以上的职责，这些职责就耦合在一起了，这种设计十分脆弱，因为当一个职

????????????? 则的变换很可能影响其他职责，会影响复用性。

????????????????????????? 这里需要对类或接口的"职责"做一些理解，SRP中将"职责"理解为“变化的原因”，当你有N

????????????? 个动机去改变类的时候，那么这个类就违法了SRP原则.

?????????????????????? Tips:这里只有你去真正修改了类的时候违反了SRP原则，如果仅仅只是一种推测，并未

??????????????? 实际付之行动，不算违反之一原则。

???????????? 单一职责原则(SRP)优点：

??????????????? 1、可以降低类的复杂度

??????????????? 2、提高类的可读性，系统的可维护性

??????????????? 3、降低变更的时候对其他功能的影响(变更不可避免)

?????????????? 简单举一个例子：关于动物吃东西的问题。

????????????????????? 编写一个类用于描述动物吃东西：

package com.kiritor;
/**
 * @author Kiritor
 * 动物类的描述*/
class Animal {
   public void eatFood(String name)
   {
	   System.out.println(name+"吃草");
   }
}

public class Client
{
	public static void main(String[] args) {
		Animal animal = new Animal();
		animal.eatFood("羊");
		animal.eatFood("牛");
	}
	
}

?????????????? 不过这里问题就来了，并不是所有动物都吃草的啊，也有肉食动物的。在不违背单一

????? 原则的情况下，我们必须将动物类细分为，肉食性和素食性的。

class AnimalMeat
{
	 public void eatFood(String name)
	   {
		   System.out.println(name+"吃肉");
	   }
}
class AnimalGlass
{
	 public void eatFood(String name)
	   {
		   System.out.println(name+"吃草");
	   }
}

public class Client
{
	public static void main(String[] args) {
		AnimalGlass animal = new AnimalGlass();
		animal.eatFood("羊");
		AnimalMeat animal2 = new AnimalMeat();
		animal2.eatFood("老虎");
	}
	
}

? ? ? ? ? ? ? ?? 由上述代码可以知道，这种修改的开销还是挺大的，不仅需要添加新类，还要修改客户

???????? 端代码。有事还不如这样修改：

class Animal{
	public void eatFoodGlass(String animal){
		System.out.println(animal+"吃草");
	}

	public void eatFoodMeat(String animal){
		System.out.println(animal+"吃肉");
	}
}

public class Client{
	public static void main(String[] args){
		Animal animal = new Animal();
		animal.eatFoodGlass("牛");
		animal.eatFoodGlass("羊");
		animal.eatFoodMeat("老虎");
	}
}

???????????? 造成上述的结果就是在使用单一原则的情况下，对于"职责"的划分没有一个明确的标准，如果

????? 把职责划分过细反而会造成接口和实现类的数量剧曾，反倒不利于维护和阅读。所以在使用这个

????? 原则的时候还是要具体问题具体分析。

??????????? 建议就是接口一定要采用单一职责原则，实现类的设计上尽可能做到单一职责原则，最好是一个

????? 原因引起一个类的变化。