设计模式原则

看了设计模式,最后看的总是感觉他们有很大的相似之处,就像是世界上万事万物都有其生存法则一样.仔细分析其实设计模式都是围绕一条主线来的。这就是设计模式的原则。你可以把设计原则比作一门语言。把设计模式当作这门语言编写出来的程序。如果你精通了语言剩下的编码就是很简单的事情了.

对于层出不穷的设计模式,比如Gof的23种设计模式,MVC模式,到底应该怎样去学习,如果我们单纯的一个一个的研究设计模式本身,那么只能是越看越多,越来越乱.其实我们只要抓住设计模式的原则,就能很清楚的分析出它为什么会这么做.

设计模式原则再加上OOP三大属性(封装,继承,多态)我们就能很清楚的理解设计模式.

首先提出一下什么是设计模式:

模式：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。

这是关于模式最经典的定义，作者是建筑大师Christopher Alexander。如果是第一次看到这句话，多数人会觉得有些抽象难懂。其实“模式”两个字只是一个代号，就像我叫李守宏，如果我改叫李四也没什么问题，只是我更喜欢李守宏这个名字，所以从Christopher开始，有了“模式”这个词，人们也都把关于“重复发生的问题的描述和解决办法”统称为模式。

“模式”这个词是不局限于软件开发行业的，它几乎无处不在，它其实就是一种经验的积累，就象大多数人的教育经历都是从小学到初中再到高中再到大学，这也是一种模式，是中国的教育模式；现在越来越火的出国热，也是另一种模式，海外留学模式。因为GOF的《设计模式：可复用面向对象软件的基础》一书描述的23种经典设计模式，奠定了模式在软件行业的地位，从此人们提到“设计模式”就是默指“面向对象设计模式”，但是模式绝对不局限于软件行业，即使在软件行业，也不局限于GOF描述的23种设计模式，例如我们常用的MVC等。

因为模式是一种经验的积累和总结，所以通过模式，我们可以站在巨人的肩膀上去思考问题、解决问题，熟练使用设计模式可以提高我们的工作效率，改善产品质量，最终带来经济效益。因此对于任何想开发出灵活高效、健壮的软件产品的个人或团体，熟练掌握并正确使用设计模式都是必须掌握的基本技能。

谈到设计模式,不能不说一下GRASP (职责分配原则),这个比模式更重要.我将再后边接着来分析.

下面我来分析一下设计模式原则,以及在设计模式中的体现.主要参考:程杰 <大话设计模块>(这里用DH代替) 和Justin Tech 的博客.

一:设计模式的核心原则是:"开-闭"原则( Open - Closed Principle 缩写:OCP ),一切的一切都是围绕着"开-闭"原则展开的

开闭原则:说软件实体(类,模块,函数等)应该可以扩展,但是不可以修改 [DH].

意思是,在一个系统中,对于扩展是开放的,对于修改是关闭的,一个好的系统是在不修改源代码的情况下,可以扩展你的功能..而实现开闭原则的关键就是抽象化.
在"开-闭"原则中,不允许修改的是抽象的类或者接口,允许扩展的是具体的实现类,抽象类和接口在"开-闭"原则中扮演着极其重要的角色..即要预知可能变化的需求.又预见所有可能已知的扩展..所以在这里"抽象化"是关键!
当然对于修改,我们不可能完全避免,也不可能完全预知到未来的变化.所以我们要做到尽量去不要修改,或者少的修改就能达到我们的目标.

例如:对于简单工厂模式.我们有能力预知到未来可能添加计算,所以,我们将运算类抽象出来.为了以后方便扩展.这里的运算类是不可以修改的.但是对于他的子类.我们是可以扩展的.

设计模式中的体现UML图

二:依赖倒转原则
A:高层模块不应该依赖底层模块 B:抽象不应该依赖细节,细节应该依赖抽象[DH]

就是说要依赖抽象,而不要依赖具体的实现..如果说开闭原则是目标,依赖倒转原则是到达"开闭"原则的手段..如果要达到最好的"开闭"原则,就要尽量的遵守依赖倒转原则..可以说依赖倒转原则是对"抽象化"的最好规范!!
通俗的说就是只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！

比如我们在观察者模式中(Observer)这里的通知者,就不应该是具体.因为我们应当考虑到如果前台那里换了人怎么办?这个通知还可以是其他人通知.比如老板要通知去做某件事怎么办?为了让大家都能用这个通知.所以要设置成抽象的.这里的前台,老板都要依赖这个通知.也就是说.细节要依赖抽象.

三:里氏代换原则:

定义:子类型必须能够替换它们的父类型[DH]
这个原则是对继承的一个约束,也就是说,继承中子类严格满足"is a "的关系.这里我个人有深刻的体会.尤其是在看别人的UML图的时候.
对你帮助很大.当你看到一个继承的时候.要习惯性的把他的父类和子类看成一个整体.这样会有助于你去理解各个类之间的关系.因为根据
里氏代换原则.父类出现的地方子类也可以出现.

比如我们再看工厂模式的时候,你看到有的书上简单工厂类关联着运算父类.有的书上是关联着运算类的子类.其实仔细想想他们都没有错,
父类和子类的关联都是一样的,父类能出现的地方,子类就可以出现.

在设计模式中的体现:
设计模式中所有继承都能体现着这一原则.我举一个不符合原则的例子.

四:单一职能原则
定义:就一个类而言,应该仅有一个引起他变化的原因[DH]

也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，
管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)
这个就是说,一个类尽量做到了功能单一,比如在mvc中,判断数据的类和添加数据库的类一定要分开.单一职能的不是说职能多了我们实现不了,是
为了后期的测试维护,每个类的很单一,我们找错误的时候就可以一步到位.添加新的功能的时候,也不用牵扯到很多的类.
在设计模式中的体现:

烤肉者就管烤肉,他也不管收钱,也不管记录.这样把"地摊"上的烤肉者分成服务员和烤肉的人.让职责单一.不容易出错.

上边的都是几个原则,下面介绍两个法则:

(1)迪米特法则:系统中的类,尽量不要与其他类互相作用,减少类之间的耦合度,因为在你的系统中,扩展的时候,你可能需要修改这些类,而类与类
之间的关系,决定了修改的复杂度,相互作用越多,则修改难度就越大,反之,如果相互作用的越小,则修改起来的难度就越小..例如A类依赖B类,
则B类依赖C类,当你在修改A类的时候,你要考虑B类是否会受到影响,而B类的影响是否又会影响到C类..如果此时C类再依赖D类的话,呵呵,
我想这样的修改有的受了..

(2)接口隔离法则:这个法则与迪米特法则是相通的,迪米特法则是目的,而接口隔离法则是对迪米特法则的规范..为了做到尽可能小的耦合性,我们
需要使用接口来规范类,用接口来约束类.要达到迪米特法则的要求,最好就是实现接口隔离法则,实现接口隔离法则,你也就满足了迪米特法则...
这里也体现了一个依赖原则,要尽量依赖抽象,不要依赖具体.
设计模式中的体现:高层模块依靠接口和底层模块依赖.

总结:学习设计模式的基础就是理解设计原则,只用理解了这些原则,加上OO的三大特性.再去体会设计模式满足那些原则.最后达到你可以运用这些原则来写出自己的设计模式来,这才是最高境界.我在看了一遍大话设计模式以后,将其中的思想总结出来.和大家分享.