最近买了本设计模式的书，名字叫《设计模式之禅》。这是我第一本设计模式的书，看了几章了感觉自己受益匪浅，所以想就把自己感觉到比较有意思的设计模式知识分享给大家。
首先说一下我们程序员为什么要学习设计模式把！下面是引用书上的原话：
你是程序员，没有问题，通过学习设计模式能够让你写出更加高效，优雅的代码；
你是架构师，那更好，设计模式可让你设计出健壮，稳定，高效的系统，并且自动地预防未来业务变化可能对系统带来的影响；
那么我们看完这几行话后，是不是有一种很想学习设计模式的感觉呢？反正我看完这几行话后特别想把书读完啊！呵呵
~~~
好了，额不再废话啦！开始切入正题吧！
设计模式分为
6
大设计原则和
23
中设计模式。
6
大设计原则
分别是：单一职责原则；里氏替换原则；依赖倒置原则；接口隔离原则；迪米特法则；开闭原则。
23
种设计模式
分别是：单例模式；工厂方法模式；抽象工厂模式；模板方法模式；建造者模式；原型模式；中介者模式；命令模式；责任链模式；装饰模式；策略模式；适配器模式；迭代器模式；组合模式；观察者模式；门面模式；备忘录模式；访问者模式；状态模式；解释器模式；享元模式；桥梁模式。
这篇博文，我想主要介绍一下
6
大设计原则中的单一职责原则。
单一职责原则的英文名称是
Single Responsibility Principle
，简称
SRP
。这个设计原则备受争议，那么争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。
RBAC
模型（
Role-Based Access Control
），基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离。下面我们来看一个类图：
通过这个接口的设计，我们可以发现有一些问题，因为用户的属性和用户的行为没有分开。我们应该把用户的信息抽取成一个
BO
（
Bussness Object
，业务对象），把行为抽取成一个
Biz
（
Business Logiz
，业务逻辑），那么我们就可以对这个类图进行修改：
分清职责后的代码就可以如下：
IUserBiz userInfo = new UserInfo();
//
实现业务对象
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("wzk");
//
实现业务逻辑
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();
下面我们还是通过一个电话通话的例子来进一步说明单一职责原则，大家都知道我们在通电话的时候会有以下过程发生：拨号，通话，回应，挂机。这个接口类图如下：
这样我们的代码就可以这样写：
//
拨通电话
void dial(string phoneNumber);
//
通话
void chat(object o);
//
通话完毕挂话
void huagup();
这是书中一段源代码，我开始认为这个接口是符合单一职责原则的，但是仔细分析后，发现它其实包含了两个职责：一个是协议管理，一个是数据传送。
dial()
和
hangup()
两个方法实现的是协议管理，分别负责拨号接通和挂机；
chat()
实现的是数据的传送。那么我们在现实生活当中协议接通和数据传送都会发生变化，所以我们可以将接口拆分成两个接口，类图如下：
这个类图就完全符合单一职责原则的要求了，每个接口职责分明，结构清晰，那么我们的手机类要把
ConnectionManager
和
DataTransfer
组合一块才能使用。组合是一种强耦合关系，都有共同的生命周期，我们使用这个强耦合关系不仅不如使用接口实现的方式，并且还增加了类的复杂性。下面我们就来修改一下这个类图：
那么通过上面的例子，说明单一职责原则有什么好处呢？引用书上一段话吧！
（1）
类的复杂性降低，实现什么职责都有清晰明确的定义。
（2）
可读性提高。
（3）
可维护性提高。
（4）
变更引起的风险降低。
注意：
单一职责原则提供了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”或“变化原因”都是不可度量的，因项目而异，因环境而异。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
