比设计模式更重要：设计原则

 原文链接：http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html

      我们生活在一个充满规则的世界里，在复杂多变的外表下，万事万物都被永恒的真理支配并有规律的运行着。模式也是一样，不论那种模式，其背后都潜藏着一些“永恒的真理”，这个真理就是设计原则。记得一次参加微软的架构师培训，期间讲到设计模式，有人问了老师一个问题：“什么东西比设计模式更重要？”，老师是一位有多年丰富实践经验的开发者，他毫不犹豫地回答到：“比模式更重要的是原则”。这句话我时常能够想起，越来越觉得这是一个伟大的答案。的确，还有什么比原则更重要呢？就像人的世界观和人生观一样，那才是支配你一切行为的根本，而对于设计模式来说，为什么这个模式要这样解决这个问题，而另一个模式要那样，它们背后都遵循的就是永恒的设计原则。可以说，设计原则是设计模式的灵魂。

对于设计原则的深入探讨我还没有那个深度，推荐大家去看《敏捷软件开发—原则、模式与实践》，下面仅对部分常用的设计原则做些简单的讲解：

   1. 单一职责原则(SRP)

   “就一个类而言，应该仅有一个引起它变化的原因。”也就是说，不要把变化原因各不相同的职责放在一起，因为不同的变化会影响到不相干的职责。再通俗一点地说就是，不该你管的事情你不要管，管好自己的事情就可以了，多管闲事害了自己也害了别人。(当然这里说的多管闲事跟见义勇为是两回事，我们提倡见义勇为！)

       例如：参考下图中的设计，图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。

            那么我们该怎么做呢？如下图，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。

              2. 开放—封闭原则(OCP)

   “软件实体(类、模块、函数等)应该是可以扩展的，但是不可修改。”嘿！多么朴实的话语，第一次看这个原则的时候我都看傻了，我当时在想“这不是&#%做白日梦吗！不修改怎么扩展啊？”但是随着学习的深入，理解了这个“不修改”是什么意思，意思是“你可以随便增加新的类，但是不要修改原来的类”。从这个角度去理解就好多了，其实这里还是一个隔离变化的问题。

       例如：如下图，有一个客户端程序通过数据访问接口操作数据，对于这套系统来说，一开始计划使用的是SQL Server或Oracle数据库，但是后来考虑到成本，改用免费的MySQL；那么对于客户端程序来说，后来数据的扩展对它没有任何影响，它在不知不觉间就用上了免费好用的MySQL数据库，这全要感谢OCP原则。

      3. 依赖倒置原则(DIP)

“抽象不应该依赖于细节。细节应该依赖于抽象。”关于这个原则，还有种说法是.“高层不应该依赖于底层，两者都应该依赖于抽象。”其实怎么说都是对的，关键就是要理解一点，只有抽象的东西才是最稳定的，也就是说，我们依赖的是它的稳定。如果将来“抽象”也不稳定了，那么谁稳定我跟谁，其实说白了不就是傍大款吗！哈哈！

例如：参考下图的设计，一个开关跟灯直接连接在一起了，也就是说开关依赖于灯的打开和关闭方法，那么如果我想用这个开关也可以打开其他东西呢，比如电视、音响。显然这个设计是无法满足这个要了，因为我们依赖了细节而不是抽象，这个开关已经等价于“灯的开关”。

       那么我们该如何来设计一个通用的开关呢？参考下图的设计，OK！现在我们不仅可以打开灯，还可以打开电视和音响，甚至未来任何实现了“开关接口”的任何东西。

 

             4. 接口隔离原则(ISP)

“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。

 例如：参考下图的设计，在这个设计里，取款、存款、转帐都使用一个通用界面接口，也就是说，每一个类都被强迫依赖了另两个类的接口方法，那么每个类有可能因为另外两个类的方法(跟自己无关)而被影响。拿取款来说，它根本不关心“存款操作”和“转帐操作”，可是它却要受到这两个方法的变化的影响，真是土鳖！！！

        那么我们该如何解决这个问题呢？参考下图的设计，为每个类都单独设计专门的操作接口，使得它们只依赖于它们关系的方法，这样就不会互相影响，也就不会在发生土鳖的事情了！

            5. 替换原则(LSP)

“子类型必须能够替换掉它们的基类型。”也就是说继承中的“IS A”关系是必须保证的，否则还算什么继承啊！如果违反了LSP原则，常会导致在运行时(RTTI)的类型判断违反OCP原则。

例如：函数A的参数是基类型，调用时传递的对象是子类型，正常情况下，增加子类型都不会影响到函数A的，如果违反了LSP，则函数A必须小心的判断传进来的具体类型，否则就会出错，这就已经违反了OCP原则。

关于模式学习

深刻理解面向对象是学好设计模式的基础，掌握一定的面向对象设计原则才能掌握面向对象设计模式的精髓，从而实现灵活运用设计模式。仅知道OO的语言机制是不够的，懂得语言里的封装、继承、多态，只是满足了最最基础的条件，要真正发挥OO的强大的作用，关键是要深刻理解以上的GRASP模式和设计原则，在此基础上去再深入理解设计模式，并在实践中不断磨练。

模式跟OO原则相比其实并不重要，如果你能设计出基本符合以上原则的程序，那么可能就已经总结出了新的模式，所以学习模式的根本是为了深入理解OO思想和原则，使我们可以写出高内聚低耦合的程序。

另外最近在学习李建忠老师的“C#面向对象设计模式纵横谈系列课程”时候，李老师提出了一个“重构到模式”的理论，感觉十分有道理，模式不完全是供我们套用的模版，在特定的业务环境下，我们实现的可能只是“类似XX模式”的设计模式，因为针对这个环境，这么使用就是最合适的，而不是什么时候都必须完全照搬GOF的23种设计模式的格式，模式是死的，而人是活的，找到最合适的实现方式就好，不要为了设计模式而使用设计模式。