=====================================================================================================================
开学前言:在接下来的时间里我将开始陆续讲解大家在开发中常用的各种“设计模式”(大概主要有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 于合肥
=============================================================================================================