最近买了本设计模式的书,名字叫《设计模式之禅》。这是我第一本设计模式的书,看了几章了感觉自己受益匪浅,所以想就把自己感觉到比较有意思的设计模式知识分享给大家。
首先说一下我们程序员为什么要学习设计模式把!下面是引用书上的原话:
你是程序员,没有问题,通过学习设计模式能够让你写出更加高效,优雅的代码;
你是架构师,那更好,设计模式可让你设计出健壮,稳定,高效的系统,并且自动地预防未来业务变化可能对系统带来的影响;
你是项目经理,也OK,设计模式可以让你的工期大大缩短,让你的项目团队队员快速地理解你的意图,最终的成果就是优质的项目:高可靠性,高稳定性,高效率和低维护成本。
那么我们看完这几行话后,是不是有一种很想学习设计模式的感觉呢?反正我看完这几行话后特别想把书读完啊!呵呵~~~
好了,额不再废话啦!开始切入正题吧!
设计模式分为6大设计原则和23中设计模式。6大设计原则分别是:单一职责原则;里氏替换原则;依赖倒置原则;接口隔离原则;迪米特法则;开闭原则。23种设计模式分别是:单例模式;工厂方法模式;抽象工厂模式;模板方法模式;建造者模式;原型模式;中介者模式;命令模式;责任链模式;装饰模式;策略模式;适配器模式;迭代器模式;组合模式;观察者模式;门面模式;备忘录模式;访问者模式;状态模式;解释器模式;享元模式;桥梁模式。
这篇博文,我想主要介绍一下6大设计原则中的单一职责原则。
单一职责原则的英文名称是Single Responsibility Principle,简称SRP。这个设计原则备受争议,那么争议之处在哪里呢?就是对职责的定义,什么是类的职责,以及怎么划分类的职责。
RBAC模型(Role-Based Access Control),基于角色的访问控制,通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离。下面我们来看一个类图:
《设计模式》杂记之单一职责原则_休闲
通过这个接口的设计,我们可以发现有一些问题,因为用户的属性和用户的行为没有分开。我们应该把用户的信息抽取成一个BOBussness Object,业务对象),把行为抽取成一个BizBusiness Logiz,业务逻辑),那么我们就可以对这个类图进行修改:
《设计模式》杂记之单一职责原则_职场_02
我们重新拆分成两个接口,IUserBO负责收集和反馈用户的属性信息,IUserBiz负责用户的行为,完成用户信息的维护和变更。
分清职责后的代码就可以如下:
IUserBiz userInfo = new UserInfo();
    //实现业务对象
    IUserBO userBO = (IUserBO)userInfo;
    userBO.setPassword("wzk");
    //实现业务逻辑
    IUserBiz userBiz = (IUserBiz)userInfo;
    userBiz.deleteUser();
上面我把一个接口分成两个接口的动作。就是依赖了单一职责原则,所以单一职责我就可以理解为:应该有且仅有一个原因引起类的变更
下面我们还是通过一个电话通话的例子来进一步说明单一职责原则,大家都知道我们在通电话的时候会有以下过程发生:拨号,通话,回应,挂机。这个接口类图如下:
《设计模式》杂记之单一职责原则_职场_03
这样我们的代码就可以这样写:
//拨通电话
        void dial(string phoneNumber);
        //通话
        void chat(object o);       
        //通话完毕挂话
        void huagup();
这是书中一段源代码,我开始认为这个接口是符合单一职责原则的,但是仔细分析后,发现它其实包含了两个职责:一个是协议管理,一个是数据传送。dial()hangup()两个方法实现的是协议管理,分别负责拨号接通和挂机;chat()实现的是数据的传送。那么我们在现实生活当中协议接通和数据传送都会发生变化,所以我们可以将接口拆分成两个接口,类图如下:
《设计模式》杂记之单一职责原则_休闲_04
这个类图就完全符合单一职责原则的要求了,每个接口职责分明,结构清晰,那么我们的手机类要把ConnectionManagerDataTransfer组合一块才能使用。组合是一种强耦合关系,都有共同的生命周期,我们使用这个强耦合关系不仅不如使用接口实现的方式,并且还增加了类的复杂性。下面我们就来修改一下这个类图:
《设计模式》杂记之单一职责原则_休闲_05
这样子设计就变成了,一个类实现了两个接口,把两个职责融合在一个类中。
那么通过上面的例子,说明单一职责原则有什么好处呢?引用书上一段话吧!
(1)       类的复杂性降低,实现什么职责都有清晰明确的定义。
(2)       可读性提高。
(3)       可维护性提高。
(4)       变更引起的风险降低。
注意:
单一职责原则提供了一个编写程序的标准,用“职责”或“变化原因”来衡量接口或类设计得是否优良,但是“职责”或“变化原因”都是不可度量的,因项目而异,因环境而异。
 
对于接口,我们在设计得时候一定要做到单一,但是对于实现类就需要考虑多方面因素了。生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦,过分细分类的职责也会人为地增加系统的复杂性。
还有就是类的单一职责可能会受很多因素的制约。比如说:项目工期,成本,人员技术水平,硬件情况,网络情况等因素。所以说对于单一职责原则,引用作者一句话就是:接口一定要做到单一职责,类的设计尽量要做到只有一个原因引起变化