设计模式——简单说单（职责原则）
|
单一职责原则的英文是Single Responsibility Principle，简称SRP。 定义：应该有且仅有一个原因引起类的变更。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会影响到其他的职责，另外，把多个职责耦合在一起，也会影响复用性。 ? 举个例子： /** * 水壶的接口 */ public interface Ikettle { public void lidButton(); ? 以上这个接口是不是一眼就看出了问题？
? ?
有人说也可以啊，那我们再加个烧水，再加个倒水。这个接口还能复用到我要生产的统一接口吗？明显有很多多余的。
? ? 这个原则备受争议，因为在设计时，要怎么去划分类的职责，什么是类的职责？ 一个职责一个接口，但问题是“职责”没有一个量化的标准，一个类到底要负责那些职责？这些职责该怎么细化？细化后是否都要有一个接口或类？ ? /** * 水壶的接口 */ 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(); }
好了可以烧水喝了。
? 以上只是简单的说明，当然还有问题和要改进的地方。有空自己思考下。。。。。如何设计？？ 这些都需要从实际的项目去考虑，从功能上来说，定义一个接口也没有错，实现了功能，而且设计简单，仅仅一个接口一个实现类，实际的项目我想大家都会这么设计。 项目考虑可变因素和不可变因素，以及相关的收益成本比率，因此设计一个接口也可能是没有错的。 过分细分类的职责也会人为地增加系统的复杂性。 ? 我是一个牛逼的类，我可以担任多职吗？ 答案当然是否定的。改起来就变成傻逼了。 ? 单一职责的好处： 1、类的复杂度降低，实现什么职责都有清晰的明确的定意； 2、可读性高 3、可维护性高 4、变更英气的风险降低 ? 单一职责适用于接口、类、同时也适用于方法。一个方法尽可能做一件事情。 ? 实践证明： 这个原则非常优秀的，但是现实有现实的难处，你必须考虑项目工期、成本、策略。 但类的设计尽量做到只有一个原因引起变化。 对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
