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