软件设计模式的原则
看了设计模式，后看的总是感觉他们有很大的相似之处，像是世界上万事万物都有其生存法则一样。仔细分析其实设计模式都是围绕一条主线来的。这是设计模式的原则。你可以把设计原则比作一门语言。把设计模式当作这门语言编写出来的程序。如果你精通了语言剩下的编码是很简单的事情了。
对于层出不穷的设计模式，比如Gof的23种设计模式，MVC模式，到底应该怎样去学习，如果我们单纯的一个一个的研究设计模式本身，那么只能是越看越多，越来越乱。其实我们只要抓住设计模式的原则，能很清楚的分析出它为什么会这么做。
设计模式原则再加上OOP三大属性(封装，继承，多态)我们能很清楚的理解设计模式。
首先提出一下什么是设计模式:
模式：每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。
这是关于模式经典的定义，作者是建筑大师ChristopherAlexander。如果是第一次看到这句话，多数人会觉得有些抽象难懂。其实“模式”两个字只是一个代号，像我叫李守宏，如果我改叫李四也没什么问题，只是我更喜欢李守宏这个名字，所以从Christopher开始，有了“模式”这个词，人们也都把关于“重复发生的问题的描述和解决办法”统称为模式。
“模式”这个词是不局限于软件开发行业的，它几乎无处不在，它其实是一种经验的积累，象大多数人的教育经历都是从小学到初中再到高中再到大学，这也是一种模式，是中国的教育模式；现在越来越火的出国热，也是另一种模式，海外留学模式。因为GOF的《设计模式：可复用面向对象软件的基础》一书描述的23种经典设计模式，奠定了模式在软件行业的地位，从此人们提到“设计模式”是默指“面向对象设计模式”，但是模式不局限于软件行业，即使在软件行业，也不局限于GOF描述的23种设计模式，例如我们常用的MVC等。
因为模式是一种经验的积累和总结，所以通过模式，我们可以站在巨人的肩膀上去思考问题、解决问题，熟练使用设计模式可以提高我们的工作效率，改善产品质量，终带来经济效益。因此对于任何想开发出灵活高效、健壮的软件产品的个人或团体，熟练掌握并正确使用设计模式都是必须掌握的基本技能。
谈到设计模式，不能不说一下GRASP(职责分配原则)，这个比模式更重要。我将再后边接着来分析。
下面我来分析一下设计模式原则，以及在设计模式中的体现。主要参考:程杰<大话设计模块>(这里用DH代替)和JustinTech的博客。
一:设计模式的核心原则是:"开-闭"原则(Open-ClosedPrinciple缩写:OCP)，一切的一切都是围绕着"开-闭"原则展开的。
开闭原则:说软件实体(类，模块，函数等)应该可以扩展，但是不可以修改[DH]。
意思是，在一个系统中，对于扩展是开放的，对于修改是关闭的，一个好的系统是在不修改源代码的情况下，可以扩展你的功能。。而实现开闭原则的关键是抽象化。
在"开-闭"原则中，不允许修改的是抽象的类或者接口，允许扩展的是具体的实现类，抽象类和接口在"开-闭"原则中扮演着极其重要的角色。即要预知可能变化的需求。又预见所有可能已知的扩展。。所以在这里"抽象化"是关键!
当然对于修改，我们不可能完全避免，也不可能完全预知到未来的变化。所以我们要做到尽量去不要修改，或者少的修改能达到我们的目标。
例如:对于简单工厂模式。我们有能力预知到未来可能添加计算，所以，我们将运算类抽象出来。为了以后方便扩展。这里的运算类是不可以修改的。但是对于他的子类。我们是可以扩展的。
设计模式中的体现UML图
二:依赖倒转原则
A:高层模块不应该依赖底层模块B:抽象不应该依赖细节，细节应该依赖抽象[DH]
是说要依赖抽象，而不要依赖具体的实现。。如果说开闭原则是目标，依赖倒转原则是到达"开闭"原则的手段。。如果要达到好的"开闭"原则，要尽量的遵守依赖倒转原则。。可以说依赖倒转原则是对"抽象化"的好规范!!
通俗的说是只有抽象的东西才是稳定的，也是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不是傍大款吗！
比如我们在观察者模式中(Observer)这里的通知者，不应该是具体。因为我们应当考虑到如果前台那里换了人怎么办?这个通知还可以是其他人通知。比如老板要通知去做某件事怎么办?为了让大家都能用这个通知。所以要设置成抽象的。这里的前台，老板都要依赖这个通知。也是说。细节要依赖抽象。
三:里氏代换原则:
定义:子类型必须能够替换它们的父类型[DH]
这个原则是对继承的一个约束，也是说，继承中子类严格满足"isa"的关系。这里我个人有深刻的体会。尤其是在看别人的UML图的时候。
对你帮助很大。当你看到一个继承的时候。要习惯性的把他的父类和子类看成一个整体。这样会有助于你去理解各个类之间的关系。因为根据里氏代换原则。父类出现的地方子类也可以出现。
比如我们再看工厂模式的时候，你看到有的书上简单工厂类关联着运算父类。有的书上是关联着运算类的子类。其实仔细想想他们都没有错，父类和子类的关联都是一样的，父类能出现的地方，子类可以出现。
在设计模式中的体现:
设计模式中所有继承都能体现着这一原则。我举一个不符合原则的例子。
四:单一职能原则
定义:一个类而言，应该仅有一个引起他变化的原因[DH]
也是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说是，不该你管的事情你不要管，管好自己的事情可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！) 这个是说，一个类尽量做到了功能单一，比如在mvc中，判断数据的类和添加数据库的类一定要分开。单一职能的不是说职能多了我们实现不了，是为了后期的测试维护，每个类的很单一，我们找错误的时候可以一步到位。添加新的功能的时候，也不用牵扯到很多的类。
在设计模式中的体现:
烤肉者管烤肉，他也不管收钱，也不管记录。这样把"地摊"上的烤肉者分成服务员和烤肉的人。让职责单一。不容易出错。
上边的都是几个原则，下面介绍两个法则:
(1)迪米特法则:系统中的类，尽量不要与其他类互相作用，减少类之间的耦合度，因为在你的系统中，扩展的时候，你可能需要修改这些类，而类与类之间的关系，决定了修改的复杂度，相互作用越多，则修改难度越大，反之，如果相互作用的越小，则修改起来的难度越小。。例如A类依赖B类，则B类依赖C类，当你在修改A类的时候，你要考虑B类是否会受到影响，而B类的影响是否又会影响到C类。。如果此时C类再依赖D类的话，呵呵，我想这样的修改有的受了。。
(2)接口隔离法则:这个法则与迪米特法则是相通的，迪米特法则是目的，而接口隔离法则是对迪米特法则的规范。。为了做到尽可能小的耦合性，我们需要使用接口来规范类，用接口来约束类。要达到迪米特法则的要求，好是实现接口隔离法则，实现接口隔离法则，你也满足了迪米特法则。。。
这里也体现了一个依赖原则，要尽量依赖抽象，不要依赖具体。
设计模式中的体现:高层模块依靠接口和底层模块依赖。
总结:学习设计模式的基础是理解设计原则，只用理解了这些原则，加上OO的三大特性。再去体会设计模式满足那些原则。后达到你可以运用这些原则来写出自己的设计模式来，这才是高境界。我在看了一遍大话设计模式以后，将其中的思想总结出来。和大家分享。
