连载:面向对象葵花宝典:思想、技巧与实践(38) - 设计模式之道

时间:2021-10-16 13:36:32

非常多人可以熟练背诵出所有的设计模式,可以高速画出各种设计模式的UML类图,也可以熟练的写出《设计模式》一书中各个模式的例子代码。

但一到实际的项目设计和开发的时候,往往都会陷入迷茫:要么无从下手,不知道哪个地方要用设计模式;要么生搬硬套。胡乱使用设计模式。将方案和代码搞得一团乱麻。


===========================================================================

【知易行难 —— 设计模式应用的问题】

形而下者谓之器。形而上者谓之道。

                                               ---《易经·系辞》

 

正如非常多流行的技术(面向对象、UML等)一样,差点儿大部分人都会宣称自己“掌握、熟练掌握”,甚至“精通”。然而。真正掌握的或者精通的,实在是少之又少。

 

一种典型的现象是:非常多人可以熟练背诵出所有的设计模式,可以高速画出各种设计模式的UML类图。也可以熟练的写出《设计模式》一书中各个模式的例子代码。

但一到实际的项目设计和开发的时候,往往都会陷入迷茫:要么无从下手,不知道哪个地方要用设计模式。要么生搬硬套。胡乱使用设计模式,将方案和代码搞得一团乱麻。

 

这是什么原因呢,难道是设计模式不好用,或者设计模式根本就是一个噱头?

答案不在于设计模式本身是否实用,而是在于我们没有掌握正确的学习和应用设计模式的方法

 

学习《设计模式》一书中的23个设计模式,仅仅是掌握了《设计模式》的“器”,但并没有掌握设计模式的“道”。

就像一个工匠,锯、钻、锤、刨样样精通。但假设不知道什么地方该用锯,什么地方该用钻,肯定是一个不合格的工匠。为了可以更好的学习和应用设计模式。我们也须要掌握设计模式的“道”。

 

设计模式的“道”就是用来指导我们什么时候用设计模式,为什么要用设计模式。23个设计模式仅仅是告诉了我们how。而设计模式之道却可以告诉我们why和where

 

【拨云见日 —— 寻找设计模式之道】

熟悉《设计模式》一书内容的同学可能会想到:《设计模式》一书中,不是每一个模式都有“适用性”的说明么?这个事实上就是回答了where和why的问题啊!

 

比如:Facade模式的“适用性”说明例如以下(摘自《设计模式》中文版一书):

 连载:面向对象葵花宝典:思想、技巧与实践(38) - 设计模式之道

上面这一段文字,看起来回答了where和why的问题,但实际上我个人感觉作用并不大。

 

首先。这段描写叙述太长了:以上这段文字是否花了你几分钟的时间去阅读和理解?

 

其次,这段描写叙述比較抽象:什么事复杂,什么叫做简单。什么叫做非常大依赖性。。。。。。

可能每一个人理解都不一样。

 

再者,23个模式,所有的“适应性”条款加起来预计有几十条条,你可以背住么?即使你可以所有背住。你可以所有理解么?即使你可以所有理解,当面对一个具体问题的时候,你知道几十条里面哪一条适应你的情况么?

 

所以,《设计模式》一书关于“适用性”的描写叙述。实际上还是太复杂,太多了,不具备非常强的实践知道意义和可操作性

 

我们须要的是一个更简单的指导思想,大道至简,最好是一两句话就行描写叙述。

幸运的是,答案居然就在《设计模式》一书中,但这个答案并非那么明显!

 

《设计模式》一书的内容側重点是23个模式的具体阐述,大部分人可能都是直奔主题。逐一去研究每一个模式。而对于开头部分第1章和第2章的内容并没有具体研读和思考,或者对于这两章仅仅是简单的浏览。并未认真领会和思考。由此错过了最重要的内容。再加上GoF在这2章的内容中。既要引入一个全新的概念,又要提纲挈领的介绍各个模式,还要引入实例进行分析,以至于大量的内容将真正核心的内容反而给淹没或者冲淡了。

 

设计模式之道就隐藏在“2.6.2 封装实现依赖关系”的最后一段,非常easy的一句话:

对变化的概念进行封装(encapsulate the concept that varies)

 

你看到这句话可能有点失望,前面分析了那么久,卖了那么多的关子,结果就这么简简单单一句话。这不是在忽悠么?

你可千万别小看了这句话,“大道至简”,设计模式之道也不例外,但“简”并不意味着没用。相反,正由于其“简”,每一个人的理解才一致,也更好掌握,实践中才更好应用。正所谓:“真传一句话。假传万卷书”。

 

GoF在《设计模式》一书中最早提出这个原则。后来不断的有其它专家进行阐述,当中《设计模式精解》(《Design pattern explained》)一书的阐述我觉得是最精辟的:Find what varies and encapsulate it,翻译一下即“找到变化,封装变化”

尽管含义和GoF描写叙述的基本一致,但其更加容易理解。

 

正所谓:踏破铁鞋无觅处,得来全不费工夫。


【庖丁解牛 —— 解析设计模式之道】

如今,让我们来深入理解“找到变化,然后封装变化”的设计模式之道。

首先。“找到变化”攻克了“在哪里”使用设计模式的问题。即回答了“where”的问题。

 

“找到变化”看起来是比較抽象的一句话,但在实践中非常好应用和操作,并且不同领域、不同行业的系统都可以完美的应用这句话。

尽管不同领域、不同行业变化的因素、方式、时机等都不一样,但每一个领域或者行业的需求分析人员、设计人员,对自己所处行业和领域的可能变化肯定是有比較深刻的理解的,什么会变化、会如何变化、什么时候会变化。。。。

。。等等,肯定都可以自己推断,这样的推断并不须要什么高深的技巧和知识水平。仅仅须要一定的经验积累。

 

假设我们刚接触一个行业或者领域,经验积累并不够。那怎么办呢?是否就无法“找到变化”了?

事实上也不然,有一个万能的办法,仅仅是要花费很多其它的精力了。

 

我的这个万能办法就是“唯一不变的是变化本身”,也就是说,假设你不知道什么会变化,那么就抱着怀疑一切的想法,一切都可能是变化的。

 

但光有这条指导原则还不行,假设我们真的抱着“一切都是可能变化的”想法。然后封装一切变化,那么就会陷入变化的漩涡无法自拔,由于变化是会递归的。A可能变成B,B也可能继续变化。于是这样无穷无尽,系统是不可能做出来的。

 

所以我们须要一个终止条件,避免陷入无穷无尽的变化递归漩涡。这个终止条件就是“有限时间内可能发生的变化”。这里的“有限时间”随行业和领域的不同而变化。比如(下面时间仅供參考):

互联网行业可以说:半年内可能发生的变化。。。。。

电信行业可以说:1年内可能发生的变化。。。。

。。

金融行业可以说:2年内可能发生的变化。。。

。。

*行业可以说:3年内可能发生的变化。

。。

 

有了这个指导原则后,你可以这样去问有经验的前辈、大虾、大牛等: XXX在1年内会发生变化么?会如何变化?

 

就这样,即使你是菜鸟,通过这么一招“借花献佛”。也可以轻松发现“变化”的地方。

 

其次,“封装变化”攻克了“为什么”使用设计模式的问题,即回答了“why”的问题。

为什么我们要用设计模式,是由于我们要封装变化!但我们为什么要封装变化呢?

答案非常明显:变化不好!

 

当然这个“不好”不是从业务的角度来说的。而是从系统的角度来说的。从业务的角度来说。“变化”是好的,变化意味着新的机会;但从系统的角度来说,变化并不好,由于变化必定要求系统修改,修改就意味着风险!

 

尽管变化给系统带来风险,但我们不能因此而“拒绝变化”,由于拒绝变化就意味着失去了机会,简单来说。赚不到钱的系统,设计再优美,功能再强大。系统再稳定。也只是是一堆没用的摆设:

客户给你提了新需求,你不做。能拿到合同么。

。。。。

行业正在兴起新的流行功能,你不做,你的系统有人用么。。。。。

一项创新带来了新的机遇,你不做。能抢占市场么。

。。。。。

 

所以我们要“拥抱变化”,但我们又不能让变化带来太大的风险,所以就提出了“封装变化”。“封装变化”意味着将变化的影响范围控制最小,将风险降到最低。

 

我们来看看,变化会带来哪些问题和风险:

1)开发者须要编码以适应变化,设计不好的方案将导致大量的编码工作量、自測工作量。

2)測试人员不单要測试因变化而新增的那部分,还要測试受影响的部分,设计不好的方案,牵一发而动全身,导致測试工作量大大添加。

3)假设为了适应某个变化而对系统做了比較大的修改,则系统的质量风险将上升。非常可能导致上线失败,或者上线后出现各种问题;

 

因此。我们要尽量降低变化带来的工作量和风险,而降低的最有效方法就是将变化的影响范围缩小,即:将变化封装起来。使其仅仅在有限的范围内有影响。

 

【举一反三 —— 活学活用设计模式之道】

就像一个武林高手有了深厚的内功。天下万物皆可成为手中的利器,而不必拘泥于具体的武器和招数一样。掌握了设计模式之道后。我们事实上也全然可以不拘泥于仅仅是用《设计模式》一书中的23个设计模式,可以依据须要选择最合适的方案。

 

比如:

不同的业务有不同的规则排列组合。规则引擎可以封装各种变化的规则。。

。。。

类之间的依赖是变化的。Spring使用XML配置文件来封装这样的变化。

。。。。

每一个银行的卡都不一样,银联封装了这样的变化,使得不同银行可以互通。。。。。

 

总之。你可以使用类和设计模式来封装变化,你也可以使用配置文件和模块来封装变化,你也可以使用一个系统来封装变化。。

。。

。。


================================================ 
转载请注明出处:http://blog.csdn.net/yunhua_lee/article/details/38315995
================================================