Posts - 100,
Articles - 1,
Comments - 328
Windows Phone & Windows中混迹的程序猿
23:48 by 王祖康, ... 阅读,
最近买了本设计模式的书，名字叫《设计模式之禅》。这是我第一本设计模式的书，看了几章了感觉自己受益匪浅，所以想就把自己感觉到比较有意思的设计模式知识分享给大家。
首先说一下我们程序员为什么要学习设计模式把！下面是引用书上的原话：
你是程序员，没有问题，通过学习设计模式能够让你写出更加高效，优雅的代码；
你是架构师，那更好，设计模式可让你设计出健壮，稳定，高效的系统，并且自动地预防未来业务变化可能对系统带来的影响；
你是项目经理，也OK，设计模式可以让你的工期大大缩短，让你的项目团队队员快速地理解你的意图，最终的成果就是优质的项目：高可靠性，高稳定性，高效率和低维护成本。
那么我们看完这几行话后，是不是有一种很想学习设计模式的感觉呢？反正我看完这几行话后特别想把书读完啊！呵呵~~~
好了，额不再废话啦！开始切入正题吧！
设计模式分为6大设计原则和23中设计模式。6大设计原则分别是：单一职责原则；里氏替换原则；依赖倒置原则；接口隔离原则；迪米特法则；开闭原则。23种设计模式分别是：单例模式；工厂方法模式；抽象工厂模式；模板方法模式；建造者模式；原型模式；中介者模式；命令模式；责任链模式；装饰模式；策略模式；适配器模式；迭代器模式；组合模式；观察者模式；门面模式；备忘录模式；访问者模式；状态模式；解释器模式；享元模式；桥梁模式。
这篇博文，我想主要介绍一下6大设计原则中的单一职责原则。
单一职责原则的英文名称是Single Responsibility Principle，简称SRP。这个设计原则备受争议，那么争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。
RBAC模型（Role-Based Access Control），基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离。下面我们来看一个类图：
通过这个接口的设计，我们可以发现有一些问题，因为用户的属性和用户的行为没有分开。我们应该把用户的信息抽取成一个BO（Bussness Object，业务对象），把行为抽取成一个Biz（Business Logiz，业务逻辑），那么我们就可以对这个类图进行修改：
我们重新拆分成两个接口，IUserBO负责收集和反馈用户的属性信息，IUserBiz负责用户的行为，完成用户信息的维护和变更。
分清职责后的代码就可以如下：
IUserBiz userInfo = new UserInfo();
&&& //实现业务对象
&&& IUserBO userBO = (IUserBO)userI
&&& userBO.setPassword("wzk");
&&& //实现业务逻辑
&&& IUserBiz userBiz = (IUserBiz)userI
&&& userBiz.deleteUser();
上面我把一个接口分成两个接口的动作。就是依赖了单一职责原则，所以单一职责我就可以理解为：应该有且仅有一个原因引起类的变更。
下面我们还是通过一个电话通话的例子来进一步说明单一职责原则，大家都知道我们在通电话的时候会有以下过程发生：拨号，通话，回应，挂机。这个接口类图如下：
这样我们的代码就可以这样写：
//拨通电话
&&&&&&& void
dial(string phoneNumber);
&&&&&&& //通话
&&&&&&& void chat(object o);&&&&&&&
&&&&&&& //通话完毕挂话
&&&&&&& void
这是书中一段源代码，我开始认为这个接口是符合单一职责原则的，但是仔细分析后，发现它其实包含了两个职责：一个是协议管理，一个是数据传送。dial()和hangup()两个方法实现的是协议管理，分别负责拨号接通和挂机；chat()实现的是数据的传送。那么我们在现实生活当中协议接通和数据传送都会发生变化，所以我们可以将接口拆分成两个接口，类图如下：
这个类图就完全符合单一职责原则的要求了，每个接口职责分明，结构清晰，那么我们的手机类要把ConnectionManager和DataTransfer组合一块才能使用。组合是一种强耦合关系，都有共同的生命周期，我们使用这个强耦合关系不仅不如使用接口实现的方式，并且还增加了类的复杂性。下面我们就来修改一下这个类图：
这样子设计就变成了，一个类实现了两个接口，把两个职责融合在一个类中。
那么通过上面的例子，说明单一职责原则有什么好处呢？引用书上一段话吧！
（1）&&&&&&
类的复杂性降低，实现什么职责都有清晰明确的定义。
（2）&&&&&&
可读性提高。
（3）&&&&&&
可维护性提高。
（4）&&&&&&
变更引起的风险降低。
单一职责原则提供了一个编写程序的标准，用&职责&或&变化原因&来衡量接口或类设计得是否优良，但是&职责&或&变化原因&都是不可度量的，因项目而异，因环境而异。
对于接口，我们在设计得时候一定要做到单一，但是对于实现类就需要考虑多方面因素了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，过分细分类的职责也会人为地增加系统的复杂性。
还有就是类的单一职责可能会受很多因素的制约。比如说：项目工期，成本，人员技术水平，硬件情况，网络情况等因素。所以说对于单一职责原则，引用作者一句话就是：接口一定要做到单一职责，类的设计尽量要做到只有一个原因引起变化。设计模式原则之一:单一职责原则
&&&&&&& 一个优良的设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP，Single Responsibility Principle）。
&&&&&&& 单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。
&&&&&& 关于单一职责原则，其核心的思想是：一个类，最好只做一件事，只有一个引起它变化的原因。
&&&&&& 单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
看下面例子：
package com.google.
public interface Program {
&& //绘制图形
&& void draw();
&& //计算面积
&& void area();
package com.google.
public class DrawGraph implements Program{
public void draw() {
&&&&&& System.out.println(&绘制图形&);
public void area() {
// TODO Auto-generated method stub
package com.google.
public class AreaCount implements Program{
public void draw() {
// TODO Auto-generated method stub
public void area() {
&&& System.out.println(&计算面积&);
以上 图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。
应该把接口改成2个，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。
package com.google.
public interface Draw {
&& //绘制图形
&& void draw();
package com.google.
public interface Area {
&& //计算面积
&& void area();
然后分别实现接口，如下：原文链接：
虽然这篇文章不是我写的，但我完全同意文章中的观点。Brian Button可能是我所知道的最有才的人之一。我相信他会喜欢你们的反馈的。
1、单例模式经常被用来为某些服务提供一个全局访问点没错，是可以这么做，但代价是什么呢？众所周知，单例模式为你的应用程序中的某些服务提供全局访问点，这样你就不必到处传递一个该服务的引用。这和一个全局变量有什么区别呢？(记住，全局变量是不好的，不是吗？)最终会发生的事情便是你设计中的依赖关系是隐藏在代码中的，这种依赖关系不能够通过检查你的类和方法的接口所见。你必须检查代码以便准确地知道你的类中都用了哪些其他对象。这可能会是不清楚的(译者注：不知道是不是这么翻译，原文：This is less clear than it could be)。冲动地创建一个全局性的东西来避免把其传来传去是你设计中的异味，这不是全局变量或者单例的功能。如果你更仔细地检查你的设计，你几乎总是能想到一种不必把&流浪数据&四处传递到每个对象和方法的更好的设计。
2、单例模式允许你限制你所创建的对象的数量这也是对的，但是现在你混合了两个不同的职责到同一个类中了，这是违反了单一职责原则的。一个类不应该关心它是否是一个单例，它应该仅仅关心它的业务职责。如果你想限制某些类的实例化能力，创建一个封装了创建并且如你所愿的那样限制创建能力的工厂或者对象生成器，这样创建职责便从业务实体职责中划分出来了。
3、单例模式促进了类之间的紧耦合使代码是可测试的一个基本属性便是它和其周围环境是松耦合的。这个属性允许你在测试过程中为了实现特定的测试目标(想想模拟对象)替换备用的合作者。单例模式把单例对象的确切类型紧耦合在一起，丧失了使用多态来替换的机会。一个更好的选择，如上面第一点所讨论到的，便是改变你的设计以便允许你传递对象的引用到你的类和方法中，这样可以减轻上述的耦合问题。
4、单例模式在程序的持续过程中一直保存着上一次的状态持久状态是单元测试的敌人。让单元测试有效的事情之一便是每个测试必须独立于其他所有测试。如果不是这样，那么测试运行的顺序会影响到测试的结果。这可能会导致测试在不应该失败的地方失败，甚至更坏的事情是仅仅因为测试的运行顺序导致测试通过。这可能会隐藏住bugs并且是邪恶的。防止状态从一个测试携带到另一个测试的一个很好办法便是避免使用静态变量。单例模式，就其本质而言，依赖于在一个静态变量中保存着一个实例。这是测试依赖的一个挑战，可以通过传递对象的引用到你的类和方法中来避免。
希望这篇文章或多或少地阐释了我对于单例模式观点。我有一个从google或者其他地方找到的一个小链接集，包括Jim Hyslop和Herb Sutter，他们同样分享了这些观点。如果你喜欢他们那么让我知道吧。
更多文章请关注我的个人博客：
阅读(...) 评论()}