六大设计原则之单一职责原则
来源:互联网 发布:参不敏 何足以知之 编辑:程序博客网 时间:2024/04/30 01:25
单一职责原则
单一职责原则(Single Responsibility Principle)–SRP:
There should never be more than one reason for a class to change.
应该有且仅有一个原因引起类的变更。
单一职责原则好处
降低类的复杂性
每个类实现单一职责,并且单一职责都有清楚明确的定义,复杂性当然降低。
提高可读性
类的复杂性降低了,当然提高了可读性了。提高可维护性
类的复杂性降低,可读性好,当然好维护。提高扩展性
变更引起的风险降低,变更是必不可少的,如果接口的单一职责做的好,一个接口修改只对相应的实现类有影响,对其它的接口没有影响,这对系统的扩展性,维护性都是有好处的。
类的单一职责原则
一般一个对象可以分为属性和行为二部分,所以在类的设计时,我们一般把对象的属性抽象成一个BO(Business Object,业务对象),把对象的行为抽象成一个Biz(Business Logic,业务逻辑)。
我们经常会管理一个系统的用户信息,比如修改一个用户的信息(id,密码,名字),添加一个用户信息,删除一个用户信息,对用户进行处理,对用户添加组织和角色。下面有一个类图,就是实现此功能的:
我们假设:
如果一个用户的属性发生改变(id,密码,名字),或者添加,删除用户都会导致类的改变,也就是说此类没有把用户的属性和用户的行为分开,导致了在有用户的属性和用户的行为变化时,UserInfo类也会改变。这就违反了我们的单一职责原则(应该有且仅有一个原因引起类的变更)。
我们按照把用户信息重新抽象成二个接口,一个IUserBO接口负责处理用户的属性,一个IUserBiz接口负责处理用户的行为,这样用户属性改变,只会导致IUserBO接口改变,用户的行为改变,只会导致IUserBiz接口改变,这样也就更符合单一职责原则。
修改后的类图如下:
我们经常使用的代码示例:
.....IUserInfo userInfo = new UserInfo();//userInfo当作IUserBO来使用IUserBO userBO = (IUserBO)userInfo;userBO.setPassword("test");//userInfo当作IUserBiz 来使用IUserBiz userBiz = (IUserBiz)userInfo;userBiz.deleteUser();.....
在实际项目中,我们经常使用这个符合单一职责原则的类图:
接口的单一职责原则
先看几个android开发中我们经常使用的接口:
- View的click监听接口OnClickListener:
在frameworks/base/core/java/android/view/View.java代码中,接口OnClickListener定义
/** * Interface definition for a callback to be invoked when a view is clicked. */ //View的click监听接口 public interface OnClickListener { void onClick(View v); }
- View的长按监听接口OnLongClickListener
在frameworks/base/core/java/android/view/View.java代码中,接口OnLongClickListener 定义:
/** * Interface definition for a callback to be invoked when a view has been clicked and held. */ //View的长按监听接口 public interface OnLongClickListener { boolean onLongClick(View v); }
- SeekBar控件的改变监听接口
-
在frameworks/base/core/java/android/widget/SeekBar.java代码中,接口OnSeekBarChangeListener 定义:
//SeekBar控件的改变监听接口public interface OnSeekBarChangeListener { //进度改变监听 void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser); //开始拖动进度条时监听 void onStartTrackingTouch(SeekBar seekBar); //拖动进度条结束时监听 void onStopTrackingTouch(SeekBar seekBar);}
从上面的三个例子,我们可以清楚的看到OnClickListener接口只针对点击功能定义onClick方法,OnLongClickListener接口只针对长按功能定义onLongClick方法,OnSeekBarChangeListener 接口针对SeekBar控件进度条改变功能定义了一组相关的三个方法。
可见,优秀接口的定义都是符合单一职责原则,针对单一的职责定义单一的方法或是相关的一组方法。
方法的单一职责原则
其实类也好,接口也好,最后归根到底还是要方法来支持和实现,所以方法的单一职责是非常关键重要的。
方法的单一职责原则简单来说就是一个方法实现一个功能,解决一个方法。
符合单一职责原则的方法,会更方便系统的调用,但是如果方法过细的拆分,也会导致方法的剧增和类或接口的复杂,因此在具体项目中还是把握一个度。
下面一个修改用户信息的样例:
一个是一个方法不符合单一职责原则,changerUser方法承担多个职责,必然导致此方法复杂,产适合其它方法来复用。
一个是每个方法都符合单一职责原则,changeUserName实现修改名字,changeHomeAddress实现修改家庭地址,changeTele实现修改电话,每个方法都职责明确清楚,逻辑也清晰明了,非常适合其它方法来调用。
总结
对于单一职责原则,我们的建议是接口一定要做到单一职责原则,类的设计尽量做到只有一个原因引起变化。
参考资料
1.设计模式之禅 第1章 单一职责原则
- 六大设计原则之“单一职责原则”
- 六大设计原则之单一职责原则
- 六大设计原则之单一职责
- 六大设计原则之单一职责
- 设计模式之禅--六大原则之单一职责原则
- 设计模式六大原则之单一职责原则
- 设计模式六大原则之(一) 单一职责原则
- 设计模式六大原则之--单一职责原则(SRP)
- 面向对象设计的六大原则之单一职责原则
- 设计模式六大原则之--单一职责原则(SRP)
- 设计模式六大原则之单一职责原则
- 设计模式六大原则之----单一职责原则
- 设计模式六大原则之单一职责原则
- 设计模式六大原则:单一职责原则
- 设计模式六大原则-------单一职责原则
- 设计模式六大原则:单一职责原则
- 设计模式六大原则---单一职责原则
- 设计模式六大原则----------单一职责原则
- 【备战NOIP2012图论专项模拟试题】砍树
- 木雨音乐 项目开发(三)主界面MainActivity
- TCP知识2
- Java函数参数的“传值”与“传引用”
- 全方位解读反射
- 六大设计原则之单一职责原则
- JZOJ.4709【NOIP2016提高A组模拟8.17】Matrix
- 计算机视觉相关领域网站整理
- MongoDB高级查询详细
- HIHO #1128 : 二分·二分查找(快速排序一半)
- Docker:搭建tomcat+mysql+web+nginx运行环境
- EL函数库
- 【概念笔记】常用标准类
- warning: non-variable type argument Any in type pattern scala.collection.immutable.Set[Any] (the und