单一职责原则的英文是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 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、变更英气的风险降低
单一职责适用于接口、类、同时也适用于方法。一个方法尽可能做一件事情。
实践证明：
这个原则非常优秀的，但是现实有现实的难处，你必须考虑项目工期、成本、策略。
但类的设计尽量做到只有一个原因引起变化。
对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。