单一职责原则的英文是Single Responsibility Principle,简称SRP。
定义:应该有且仅有一个原因引起类的变更。
如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会影响到其他的职责,另外,把多个职责耦合在一起,也会影响复用性。
举个例子:
/** * 水壶的接口 */ public interface Ikettle { public void lidButton(); public void powerButton(); public void powerConnector(); public void getWater(); }
以上这个接口是不是一眼就看出了问题?
我们只要这个水壶的接口。
然而他却打开了盖子给自己装水了。好像不太需要。
有人说也可以啊,那我们再加个烧水,再加个倒水。这个接口还能复用到我要生产的统一接口吗?明显有很多多余的。
这个原则备受争议,因为在设计时,要怎么去划分类的职责,什么是类的职责?
一个职责一个接口,但问题是“职责”没有一个量化的标准,一个类到底要负责那些职责?这些职责该怎么细化?细化后是否都要有一个接口或类?
/** * 水壶的接口 */ public interface Ikettle { public void openLid(); public void closeLid(); public void powerOnButton(); public void powerOffButton(); public void powerOnConnecter(); public void powerOffConnecter(); }
我准备生成一个水壶了:
public class Midea1601 implements Ikettle{ @Override public void openLid() { // TODO Auto-generated method stub } @Override public void closeLid() { // TODO Auto-generated method stub } @Override public void powerOnButton() { // TODO Auto-generated method stub } @Override public void powerOffButton() { // TODO Auto-generated method stub } @Override public void powerOnConnecter() { // TODO Auto-generated method stub } @Override public void powerOffConnecter() { // TODO Auto-generated method stub } @Override public void getWater() { // TODO Auto-generated method stub } }
我们要使用了:
public class UseKettle { public static void main(String[] args) { // TODO Auto-generated method stub Midea1601 kettle= new Midea1601(); } }
然后你突然发现没有法用啊??!!
没办法装水啊等等。。。
看来要教教了。。。
public interface IUseKettle { public void getWater(int waterLevel); public void boilWater(); public void outWater(int waterLevel); }
到了出厂了总是要拿来直接用的,改改吧。。
public class Midea1601 implements Ikettle,IUseKettle{ @Override public void getWater(int waterLevel) { // TODO Auto-generated method stub openLid(); int level =0; for(int i=0;i<waterLevel;i++) { level++; try { Thread.sleep(1000); }catch(Exception e) { } } closeLid(); } @Override public void boilWater() { // TODO Auto-generated method stub int temperature =0; for(int i=0;i<100;i++) { temperature++; try { Thread.sleep(1000); }catch(Exception e) { } } } @Override public void outWater(int waterLevel) { // TODO Auto-generated method stub openLid(); int level =0; for(int i=0;i<waterLevel;i++) { level++; try { Thread.sleep(1000); }catch(Exception e) { } } closeLid(); } @Override public void openLid() { // TODO Auto-generated method stub } @Override public void closeLid() { // TODO Auto-generated method stub } @Override public void powerOnButton() { // TODO Auto-generated method stub } @Override public void powerOffButton() { // TODO Auto-generated method stub } @Override public void powerOnConnecter() { // TODO Auto-generated method stub } @Override public void powerOffConnecter() { // TODO Auto-generated method stub } @Override public void getWater() { // TODO Auto-generated method stub } }
public static void main(String[] args) { // TODO Auto-generated method stub Midea1601 kettle= new Midea1601(); int waterLevel =100; kettle.getWater(waterLevel); kettle.boilWater(); kettle.outWater(50);
}
好了可以烧水喝了。
以上只是简单的说明,当然还有问题和要改进的地方。有空自己思考下。。。。。如何设计??
这些都需要从实际的项目去考虑,从功能上来说,定义一个接口也没有错,实现了功能,而且设计简单,仅仅一个接口一个实现类,实际的项目我想大家都会这么设计。
项目考虑可变因素和不可变因素,以及相关的收益成本比率,因此设计一个接口也可能是没有错的。
过分细分类的职责也会人为地增加系统的复杂性。
我是一个牛逼的类,我可以担任多职吗?
答案当然是否定的。改起来就变成傻逼了。
单一职责的好处:
1、类的复杂度降低,实现什么职责都有清晰的明确的定意;
2、可读性高
3、可维护性高
4、变更英气的风险降低
单一职责适用于接口、类、同时也适用于方法。一个方法尽可能做一件事情。
实践证明:
这个原则非常优秀的,但是现实有现实的难处,你必须考虑项目工期、成本、策略。
但类的设计尽量做到只有一个原因引起变化。
对于接口,我们在设计的时候一定要做到单一,但是对于实现类就需要多方面考虑了。