1、设计模式之----单一职责原则

=====================================================================================================================

 

      开学前言：在接下来的时间里我将开始陆续讲解大家在开发中常用的各种“设计模式”(大概主要有23中之多，我会一个模式一篇博客的进行讲解，由于时间有限---这个大家都能理解吧，程序员的时间真他妈的有限，我只能争取一个星期写一两篇，谅解！)，由于本人知识技术水平有限，再加上设计模式本身的博大精深和复杂多义，理解出错在所难免，在此只是记录个人的理解，只做抛砖，希望引玉。如有错误或理解不当之处，希望各位同仁志士及时回帖斧正披露，共同交流学习。我会根据大家的指点及时修正bug(没有bug的软件是不完美的，没有bug的博客是假的，没有bug的人不是人！)，希望通过共同的努力使接下来的模式讲解走向完美，为想要学习“设计模式”的过客尽零星之力。

对所有的过客，无论是否留下自己的脚印，我在此都先一一谢过！

 

     好！闲话少叙，我们开始步入正轨，进入第一个设计模式的学习。

 

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

     单一职责原则(Single Responsibility principle:SRP)

 

我们学东西都是从易到难，从小到大，你接受的任何课本、书籍、教育应该都是这个模式(从易到难)，所以这第一个模式非常简单，比较基础，见名知意，不用我多说大家应该都知道是什么意思了吧？！不过虽然基础简单，但你不能小看，越是基础简单的东西，你越要深入透彻的学习掌握，来不得半点假。记得《士兵突击》(一部出色的励志电视剧，大家应该都看过吧)中的那个团长说过这样一句换：看似简单的事情，有时候又蛮复杂；而看似复杂的事情，有时候又蛮简单。

 

     1、解释

中文解释：应该有且仅有一个原因引起类的变更。

英文解释：There should never be more than one reason for a class to change.

自己理解：在我们的开发中，从接口、类到方法都要“单一职责”化，也即，你在设计接口、类或者方法时尽量让他们各司其职，仅干一件事情，而不是干多个事情。按照这个模式的要求，程序界接收“专才”，拒绝“通才”或者“综合人才”。

 

     2、实用范围

基本任何项目任何地方都能用到，也都要用到(也许你不知不觉的一直在用，只是不知道它是“单一职责原则”而已)。宏观上说，该原则主要用在接口、类和方法中。

 

     3、举例说明

下面我就使用我们经常开发的“用户管理”模块进行举例说明(“系统管理”模块，大家应该非常清楚吧？！)，该模块无非就是对系统用户进行增删改查以及权限分配操作。

 

①、接口举例：

/**
 * 系统用户管理服务类
 * 
 * @author 蜘蛛
 * @date	2011-01-12 00:53
 */
public interface ISystemUserManager {
	//注入用户名
	public void setUserName(String userName);
	//注入用户密码
	public void setPassword(String password);
	//获取用户名
	public String getUserName();
	//获取用户密码
	public String getPassword();
	//保存一个新的用户到数据库
	public boolean saveUser(String userName, String password);
	//修改一个已经存在的用户
	public boolean updateUser(Integer id, String userName, String password);
	//deleteUser和findUsers略........
}

上面这个系统用户管理服务接口就严重违反了“单一职责原则”，它想一口吃个胖子，不仅管理着系统用户的基本信息，而且负责者用户数据的持久化操作(如果你在项目开发中这么干，我想你的项目经理一定会踹你一脚，一般都是在心里暗暗地踹你一脚，不过你要记住这一脚！)。下面按照“单一职责原则”进行修改：

 

/**
 * 系统用户基本信息管理服务类
 * 
 * @author 蜘蛛
 * @date	2011-01-12 01:04
 */
public interface ISystemUser {

	//注入用户名
	public void setUserName(String userName);
	//注入用户密码
	public void setPassword(String password);
	//获取用户名
	public String getUserName();
	//获取用户密码
	public String getPassword();
	
}

 

 

/**
 * 系统用户持久化管理服务类
 * 
 * @author 蜘蛛
 * @date	2011-01-12 01:04
 */
public interface ISystemUserManager {

	//保存一个新的用户到数据库
	public boolean saveUser(ISystemUser user);
	//修改一个已经存在的用户
	public boolean updateUser(ISystemUser user);
	//deleteUser和findUsers略........
	
}

  经过修改，将原来一个接口负责的任务分给了两个接口来完成，这样每个接口的职责更加单一，更加单纯了！这就符合了“单一职责原则”。

 

       ②、类举例

类与接口差不多。实现上面第一个接口的用户管理服务类就违反了“单一职责原则”，实现上面2和3两个接口而产生的进行系统用户管理的服务类就是符合“单一职责原则”的。如果你有时间，想深刻领会“设计模式”的深刻内涵的话，可以自己写写看。

 

      ③、方法举例

 

/**
 * 系统用户管理
 * 
 * @author 蜘蛛
 * @date	2010-01-12 01:17
 */
public class SystemUserManager {
	
	/**系统用户信息实体bean*/
	private SystemUser user;
	
	/**
	 * 用户持久化操作
	 * 
	 * @param flag(1:保存，2:修改，3:删除，4:查询所有)
	 */
	public void managerUser(int flag) {
		if (1 == flag) {
			//进行保存用户操作save
		} else if (2 == flag) {
			//进行修改用户信息操作update
		} else if (3 == flag) {
			//进行删除用户操作delete
		} else {
			//进行用户信息查找操作findAll
		}
	}
	
}

 上面这个方法就严重违反了“单一职责原则”，可以看到这个方法就成了程序界的通才，下面要将他修改为专才，从而符合“单一职责原则”的要求。

 

/**
 * 系统用户管理
 * 
 * @author 蜘蛛
 * @date	2010-01-12 01:25
 */
public class SystemUserManager {
	
	/**
	 * 新增用户
	 * 
	 * @param user
	 * @return
	 */
	public boolean saveUser(SystemUser user) {
		//具体实现代码
	}
	
	/**
	 * 修改用户信息
	 * 
	 * @param user
	 * @return
	 */
	public boolean updateUser(SystemUser user) {
		//具体实现代码
	}
	
	/**
	 * 删除用户信息
	 * 
	 * @param user
	 * @return
	 */
	public int deleteUser(SystemUser user) {
		//具体实现代码
	}
	
	/**
	 * 查询所有用户信息
	 * 
	 * @return
	 */
	public List<SystemUser> findAllUsers() {
		//具体实现代码
	}
}

 

  经过修改整理，上面这些方法都是符合“单一职责原则”的，他们共同分担了上面第一个方法“public void managerUser(int flag) ”负责的重任。

 

看到这里大家应该对单一职责原则有一定的了解了吧？希望大家能从中学到一些东西。不至于浪费各位过客的宝贵时间。

 

最后补充一点
理论终究是理论，我们不能死板硬套，不是用了设计模式就是好的程序代码，不用就一定“垃圾”，实际项目开发中，我们要一切从实际出发，

灵活多变，不要为了使用“设计模式”而使用“设计模式”。

实际项目开发要受诸多因素的影响，你必须考虑项目工期、成本、人员技术水平等等。 要做到正确抉择、灵活使用就得靠大家慢慢在工作当中去学习、去领会了！这里我就帮不了各位了！！！

 

哎！又快2:00点了，劳累了一天该休息会了，下一个设计模式是“里氏替换原则”，我尽量尽快抽时间开写，大家少待。。。。。。。。。。。。

 

第一个设计模式就讲到讲到这里了，我理解的几乎也就这么多了，如果没有说明白望大家谅解；如果有遗漏之处望回帖赐教补充；如有错误望回帖斧正。

 

蜘蛛(夜间默默地工作着-----享受着加班熬夜的痛苦)

 

2011-01-12 01:47:05 于合肥

=============================================================================================================