开篇-模式和原则
前言
正式接触使用设计模式近两年了,一直想写点东西来巩固所学,但是迟迟没有动作,总想时间和见识再多一些的时候再动笔,但是拖得越久越感觉合适的时机永远不会有,只有不断实践才能换来进步,也许再不写就永远也写不出来了,于是我终于开始了。
谈到设计模式,应该还没有人能超越GOF的开山之作,所以谈不上什么创新,归根结底还是重复前人的论述和思想,更多的只能是整理和个人的一些心得体会。因为从设计模式诞生以来,业界还是发生了很大的变化的,开发工具和开发过程已经更新换代了很多次,所以很多模式在现在已经不是很常用了,这次计划只重点介绍最流行的模式,以后会逐渐补充其它的模式。(参看下面的提纲)
这个系列计划以《Head First Design Patterns》的结构为主线,也可以说是这本书的学习笔记,但是更多的是学习原书循序渐进的讲解方式,再争取加入更多个人的思想和见解,希望最后能引起大家的共鸣。
园子里已经有好几位大侠和前辈写过设计模式系列的文章了,我从他们那曾经吸收了太多的精华,大恩不言谢,我这里还是谢过了。
提纲
下面是这个系列的提纲初稿,将来会根据实际情况做适当的增删。
开篇-模式和原则
1. 鸭子-策略模式
2. 气象站的故事-观察者模式
3. 来杯咖啡-装饰者模式
4. 美味比萨-工厂模式
5. 巧克力-单件模式
6. 遥控器-命令模式
7. 家庭剧院-适配器和门面模式
8. 好莱坞原则-模板方法模式
9. 餐厅菜单-迭代器和合成模式
10. 糖果机-状态模式
11. 首席代表-代理模式
12. 鸭子重出江湖-复合使用模式
13. 用模式思考-与模式相处
14. 剩下的模式
设计模式介绍
模式:每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。
这是关于模式最经典的定义,作者是建筑大师Christopher Alexander。如果是第一次看到这句话,多数人会觉得有些抽象难懂。其实“模式”两个字只是一个代号,就像我叫Justin,如果我改叫Tom也没什么问题,只是我更喜欢Justin这个名字,所以从Christopher开始,有了“模式”这个词,人们也都把关于“重复发生的问题的描述和解决办法”统称为模式。
“模式”这个词是不局限于软件开发行业的,它几乎无处不在,它其实就是一种经验的积累,就象大多数人的教育经历都是从小学到初中再到高中再到大学,这也是一种模式,是中国的教育模式;现在越来越火的出国热,也是另一种模式,海外留学模式。因为GOF的《设计模式:可复用面向对象软件的基础》一书描述的23种经典设计模式,奠定了模式在软件行业的地位,从此人们提到“设计模式”就是默指“面向对象设计模式”,但是如前文所述,模式绝对不局限于软件行业,即使在软件行业,也不局限于GOF描述的23种设计模式,例如最著名的Martin Flower的《企业架构模式》,还有我们常用的MVC、IOC等。
[说到这里,有必要声明一下的是,在该系列文章中,凡提到模式,都是指软件行业的基于GOF的《设计模式:可复用面向对象软件的基础》一书的面向对象设计模式,GRASP模式除外。]
因为模式是一种经验的积累和总结,所以通过模式,我们可以站在巨人的肩膀上去思考问题、解决问题,熟练使用设计模式可以提高我们的工作效率,改善产品质量,最终带来经济效益。因此对于任何想开发出灵活高效、健壮的软件产品的个人或团体,熟练掌握并正确使用设计模式都是必须掌握的基本技能。
所以,让我们开始吧……
比设计模式更重要:GRASP (职责分配原则)
要学习设计模式,有些基础知识是我们必须要先知道的,设计模式是关于类和对象的一种高效、灵活的使用方式,也就是说,必须先有类和对象,才能有设计模式的用武之地,否则一切都是空谈,那么类和对象是从那冒出来的呢?这时就需要比23种设计模式更重要更经典的GRASP模式登场了,嘿嘿,原来这才是老大!
GRASP(General Responsibility Assignment Software Patterns),中文名称为“通用职责分配软件模式”,GRASP一共包括9种模式,它们描述了对象设计和职责分配的基本原则。也就是说,如何把现实世界的业务功能抽象成对象,如何决定一个系统有多少对象,每个对象都包括什么职责,GRASP模式给出了最基本的指导原则。初学者应该尽快掌握、理解这些原则,因为这是如何设计一个面向对象系统的基础。可以说,GRASP是学习使用设计模式的基础。
1. Information Expert (信息专家)
信息专家模式是面向对象设计的最基本原则,是我们平时使用最多,应该跟我们的思想融为一体的原则。也就是说,我们设计对象(类)的时候,如果某个类拥有完成某个职责所需要的所有信息,那么这个职责就应该分配给这个类来实现。这时,这个类就是相对于这个职责的信息专家。
例如:常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次,购买相同商品,只需要更新商品的数量即可。如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/0ac034bdaebb2a94652ba18badad3d87.jpeg)
2. Creator (创造者)
实际应用中,符合下列任一条件的时候,都应该由类A来创建类B,这时A是B的创建者:
a. A是B的聚合
b. A是B的容器
c. A持有初始化B的信息(数据)
d. A记录B的实例
e. A频繁使用B
如果一个类创建了另一个类,那么这两个类之间就有了耦合,也可以说产生了依赖关系。依赖或耦合本身是没有错误的,但是它们带来的问题就是在以后的维护中会产生连锁反应,而必要的耦合是逃不掉的,我们能做的就是正确地创建耦合关系,不要随便建立类之间的依赖关系,那么该如何去做呢?就是要遵守创建者模式规定的基本原则,凡是不符合以上条件的情况,都不能随便用A创建B。
例如:因为订单(Order)是商品(SKU)的容器,所以应该由订单来创建商品。如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/a1412cbc9ed60b59725e8c12ca3dc5ed.jpeg)
3. Low coupling (低耦合)
低耦合模式的意思就是要我们尽可能地减少类之间的连接。
其作用非常重要:
a. 低耦合降低了因一个类的变化而影响其他类的范围。
b. 低耦合使类更容易理解,因为类会变得简单,更内聚。
下面这些情况会造成类A、B之间的耦合:
a. A是B的属性
b. A调用B的实例的方法
c. A的方法中引用了B,例如B是A方法的返回值或参数。
d. A是B的子类,或者A实现了B
关于低耦合,还有下面一些基本原则:
a. Don’t Talk to Strangers原则:
意思就是说,不需要通信的两个对象之间,不要进行无谓的连接,连接了就有可能产生问题,不连接就一了百了啦!
b. 如果A已经和B有连接,如果分配A的职责给B不合适的话(违反信息专家模式),那么就把B的职责分配给A。
c. 两个不同模块的内部类之间不能直接连接,否则必招报应!嘿!
例如:Creator模式的例子里,实际业务中需要另一个出货人来清点订单(Order)上的商品(SKU),并计算出商品的总价,但是由于订单和商品之间的耦合已经存在了,那么把这个职责分配给订单更合适,这样可以降低耦合,以便降低系统的复杂性。如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/b190bb23f4bb38126814566d71de249d.jpeg)
4. High cohesion (高内聚)
高内聚的意思是给类尽量分配内聚的职责,也可以说成是功能性内聚的职责。即功能性紧密相关的职责应该放在一个类里,并共同完成有限的功能,那么就是高内聚合。这样更有利于类的理解和重用,也便于类的维护。
高内聚也可以说是一种隔离,就想人体由很多独立的细胞组成,大厦由很多砖头、钢筋、混凝土组成,每一个部分(类)都有自己独立的职责和特性,每一个部分内部发生了问题,也不会影响其他部分,因为高内聚的对象之间是隔离开的。
例如:一个订单数据存取类(OrderDAO),订单即可以保存为Excel模式,也可以保存到数据库中;那么,不同的职责最好由不同的类来实现,这样才是高内聚的设计,如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/5a5ab1eff9c2ee640fc63bd1be7bf16a.jpeg)
5. Controller (控制器)
用来接收和处理系统事件的职责,一般应该分配给一个能够代表整个系统的类,这样的类通常被命名为“XX处理器”、“XX协调器”或者“XX会话”。
关于控制器类,有如下原则:
a. 系统事件的接收与处理通常由一个高级类来代替。
b. 一个子系统会有很多控制器类,分别处理不同的事务。
关于这个模式更详细的论述,请参考《UML和模式应用》第16章。
6. Polymorphism (多态)
这里的多态跟OO三大基本特征之一的“多态”是一个意思。
例如:我们想设计一个绘图程序,要支持可以画不同类型的图形,我们定义一个抽象类Shape,矩形(Rectangle)、圆形(Round)分别继承这个抽象类,并重写(override)Shape类里的Draw()方法,这样我们就可以使用同样的接口(Shape抽象类)绘制出不同的图形,如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/f0ff68e2213e3418c51d86a08bc5de32.jpeg)
7. Pure Fabrication (纯虚构)
这里的纯虚构跟我们常说的纯虚构函数意思相近。高内聚低耦合,是系统设计的终极目标,但是内聚和耦合永远都是矛盾对立的。高内聚以为这拆分出更多数量的类,但是对象之间需要协作来完成任务,这又造成了高耦合,反过来毅然。该如何解决这个矛盾呢,这个时候就需要纯虚构模式,由一个纯虚构的类来协调内聚和耦合,可以在一定程度上解决上述问题。
例如:上面多态模式的例子,如果我们的绘图程序需要支持不同的系统,那么因为不同系统的API结构不同,绘图功能也需要不同的实现方式,那么该如何设计更合适呢?如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/b95ce9b67055c221afc1fa70e174b6db.jpeg)
8. Indirection (间接)
“间接”顾名思义,就是这个事不能直接来办,需要绕个弯才行。绕个弯的好处就是,本来直接会连接在一起的对象彼此隔离开了,一个的变动不会影响另一个。就想我在前面的低耦合模式里说的一样,“两个不同模块的内部类之间不能直接连接”,但是我们可以通过中间类来间接连接两个不同的模块,这样对于这两个模块来说,他们之间仍然是没有耦合/依赖关系的。
9. Protected Variations (受保护变化)
预先找出不稳定的变化点,使用统一的接口封装起来,如果未来发生变化的时候,可以通过接口扩展新的功能,而不需要去修改原来旧的实现。也可以把这个模式理解为OCP(开闭原则)原则,就是说一个软件实体应当对扩展开发,对修改关闭。在设计一个模块的时候,要保证这个模块可以在不需要被修改的前提下可以得到扩展。这样做的好处就是通过扩展给系统提供了新的职责,以满足新的需求,同时又没有改变系统原来的功能。关于OCP原则,后面还会有单独的论述。
比设计模式更重要:设计原则
我们生活在一个充满规则的世界里,在复杂多变的外表下,万事万物都被永恒的真理支配并有规律的运行着。模式也是一样,不论那种模式,其背后都潜藏着一些“永恒的真理”,这个真理就是设计原则。记得一次参加微软的架构师培训,期间讲到设计模式,有人问了老师一个问题:“什么东西比设计模式更重要?”,老师是一位有多年丰富实践经验的开发者,他毫不犹豫地回答到:“比模式更重要的是原则”。这句话我时常能够想起,越来越觉得这是一个伟大的答案。的确,还有什么比原则更重要呢?就像人的世界观和人生观一样,那才是支配你一切行为的根本,而对于设计模式来说,为什么这个模式要这样解决这个问题,而另一个模式要那样,它们背后都遵循的就是永恒的设计原则。可以说,设计原则是设计模式的灵魂。
对于设计原则的深入探讨我还没有那个深度,推荐大家去看《敏捷软件开发—原则、模式与实践》,下面仅对部分常用的设计原则做些简单的讲解:
1. 单一职责原则(SRP)
“就一个类而言,应该仅有一个引起它变化的原因。”也就是说,不要把变化原因各不相同的职责放在一起,因为不同的变化会影响到不相干的职责。再通俗一点地说就是,不该你管的事情你不要管,管好自己的事情就可以了,多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事,我们提倡见义勇为!)
例如:参考下图中的设计,图形计算程序只使用了正方形的Area()方法,永远不会使用Draw()方法,而它却跟Draw方法关联了起来。这违反了单一原则,如果未来因为图形绘制程序导致Draw()方法产生了变化,那么就会影响到本来毫不关系的图形计算程序。
![](https://i-blog.csdnimg.cn/blog_migrate/f0c8ee26d9acacf82eafc7592c8bd9ac.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/03068faad7b5d1e80ea5525c6c67220f.jpeg)
“软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。”嘿!多么朴实的话语,第一次看这个原则的时候我都看傻了,我当时在想“这不是&#%做白日梦吗!不修改怎么扩展啊?”但是随着学习的深入,理解了这个“不修改”是什么意思,意思是“你可以随便增加新的类,但是不要修改原来的类”。从这个角度去理解就好多了,其实这里还是一个隔离变化的问题。
例如:如下图,有一个客户端程序通过数据访问接口操作数据,对于这套系统来说,一开始计划使用的是SQL Server或Oracle数据库,但是后来考虑到成本,改用免费的MySQL;那么对于客户端程序来说,后来数据的扩展对它没有任何影响,它在不知不觉间就用上了免费好用的MySQL数据库,这全要感谢OCP原则。
![](https://i-blog.csdnimg.cn/blog_migrate/529c95490288b449b3b1807aa28ced2b.jpeg)
3. 依赖倒置原则(DIP)
“抽象不应该依赖于细节。细节应该依赖于抽象。”关于这个原则,还有种说法是.“高层不应该依赖于底层,两者都应该依赖于抽象。”其实怎么说都是对的,关键就是要理解一点,只有抽象的东西才是最稳定的,也就是说,我们依赖的是它的稳定。如果将来“抽象”也不稳定了,那么谁稳定我跟谁,其实说白了不就是傍大款吗!哈哈!
例如:参考下图的设计,一个开关跟灯直接连接在一起了,也就是说开关依赖于灯的打开和关闭方法,那么如果我想用这个开关也可以打开其他东西呢,比如电视、音响。显然这个设计是无法满足这个要了,因为我们依赖了细节而不是抽象,这个开关已经等价于“灯的开关”。
![](https://i-blog.csdnimg.cn/blog_migrate/0b6e122f3c04c9e2d92781e66aff66e6.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/87a512c0ea4b2ae1de4d7a64f03069da.jpeg)
“不应该强迫客户依赖于它们不用的方法。接口属于客户,不属于它所在的类层次结构。”这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使用的方法,那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
例如:参考下图的设计,在这个设计里,取款、存款、转帐都使用一个通用界面接口,也就是说,每一个类都被强迫依赖了另两个类的接口方法,那么每个类有可能因为另外两个类的方法(跟自己无关)而被影响。拿取款来说,它根本不关心“存款操作”和“转帐操作”,可是它却要受到这两个方法的变化的影响,真是土鳖!!!
![](https://i-blog.csdnimg.cn/blog_migrate/0ea37cf7a5d936f78e10b6933c9c6f7d.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/aee77d49a22ca79ef1c490f573bec73b.jpeg)
“子类型必须能够替换掉它们的基类型。”也就是说继承中的“IS A”关系是必须保证的,否则还算什么继承啊!如果违反了LSP原则,常会导致在运行时(RTTI)的类型判断违反OCP原则。
例如:函数A的参数是基类型,调用时传递的对象是子类型,正常情况下,增加子类型都不会影响到函数A的,如果违反了LSP,则函数A必须小心的判断传进来的具体类型,否则就会出错,这就已经违反了OCP原则。
关于模式学习
深刻理解面向对象是学好设计模式的基础,掌握一定的面向对象设计原则才能掌握面向对象设计模式的精髓,从而实现灵活运用设计模式。仅知道OO的语言机制是不够的,懂得语言里的封装、继承、多态,只是满足了最最基础的条件,要真正发挥OO的强大的作用,关键是要深刻理解以上的GRASP模式和设计原则,在此基础上去再深入理解设计模式,并在实践中不断磨练。
模式跟OO原则相比其实并不重要,如果你能设计出基本符合以上原则的程序,那么可能就已经总结出了新的模式,所以学习模式的根本是为了深入理解OO思想和原则,使我们可以写出高内聚低耦合的程序。
另外最近在学习李建忠老师的“C#面向对象设计模式纵横谈系列课程”时候,李老师提出了一个“重构到模式”的理论,感觉十分有道理,模式不完全是供我们套用的模版,在特定的业务环境下,我们实现的可能只是“类似XX模式”的设计模式,因为针对这个环境,这么使用就是最合适的,而不是什么时候都必须完全照搬GOF的23种设计模式的格式,模式是死的,而人是活的,找到最合适的实现方式就好,不要为了设计模式而使用设计模式。
作者
王晓亮/Justin
Mail:xiaoliang.justin@gmail.com
参考资料
《UML和模式应用》
《敏捷软件开发—原则、模式与实践》
出处: http://justinw.cnblogs.com/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。