设计模式入门—设计模式原则

这篇文章, 不需要你一次就看懂 , 如果你真的能一次都看懂 , 我想 设计 模式 对于你来说已经没什么难度了.. 因为设计模式就是要体现这些原则的 , 你可以把设计原则看做是一门语言 , 设计模式是由这些语言编码的程序 .. 你既然已经明白 , 精通了语言 , 剩下的编码自然是很简单的事情 , 编码的越多则经验越多 , 经验越多则对原则的理解就越深 ... 这是一个 学习 领悟 的过程..

     我希望这篇文章能帮助新人感受到 设计模式的乐趣 , 避免重复编码 .... 减少劳动量 .. 如果你能在用心静静的体会文章的每个字 , 每段话的意思 , 这样可以避免走很多弯路 ... 我以前学习设计模式的时候 , 就是 因为忽略了原则 , 凭着感觉 , 看着书来学习设计模式 , 结果就是知其然而不知其所以然 .... 如果你是初学设计模式 , 再了解了 OOP 的三大原则 ( 封套 , 继承 ,  多态 ) 之后 , 请反复的结合原则 , 来学习设计模式 .. 这样可以达到事半功倍的效果 ...
  
     设计模式的核心原则是:" 开 - 闭 " 原则 (  Open - Closed Principle  缩写 :OCP  ), 一切的一切都是围绕着 " 开 - 闭 " 原则展开的 ..
     意思是, 在一个 系统 中, 对于扩展是开放的 , 对于修改是关闭的 , 一个好的系统是在不修改源 代码 的情况下, 可以扩展你的功能 .. 而实现开闭原则的关键就是抽象化 .
     在" 开 - 闭 " 原则中 , 不允许修改的是抽象的类或者接口 , 允许扩展的是具体的实现类 , 抽象类和接口在 " 开 - 闭 " 原则中扮演着极其重要的角色 .. 即要预知可能变化的需求 . 又预见所有可能已知的扩展 .. 所以在这里 " 抽象化 " 是关键 !!!

      可变性的封闭原则: 找到系统的可变因素 , 将它封装起来 .. 这是对 " 开 - 闭 " 原则最好的实现 .. 不要把你的可变因素放在多个类中 , 或者散落在程序的各个角落 .. 你应该将可变的因素 , 封套起来 .. 并且切忌不要把所用的可变因素封套在一起 .. 最好的解决办法是 , 分块封套你的可变因素 !! 避免超大类 , 超长类 , 超长 方法 的出现!! 给你的程序增加艺术气息 , 将程序艺术化是我们的目标 !!

      里氏代换原则: 任何基类可以出现的地方 , 子类也可以出现 .. 如果你通读过<Java 编程思想 >, 我想你应该明白这个原则 , 在书中 ,Bruce Eckel  大师用了大量的章节来讲解 " 向上转型 " 和 " 向下转型 ", 我想目的很清楚 , 不仅是要你明白类的型别 , 更重要的是要你明白父类与子类的关系 ..

      依赖倒转原则: 要依赖抽象 , 而不要依赖具体的实现 .. 如 果说开闭原则是目标, 依赖倒转原则是到达 " 开闭 " 原则的手段 .. 如果要达到最好的 " 开闭 " 原则 , 就要尽量的遵守依赖倒转原则 .. 可以说依赖倒转原则是对 "  抽象化 " 的最好规范 !! 我个人感觉 , 依赖倒转原则也是里氏代换原则的补充 .. 你理解了里氏代换原则 , 再来理解依赖倒转原则应该是很容易的 ..
  合成/ 聚合原则 : 要尽量使用合成 / 聚合原则 , 而不是继承关系达到软件复用的目的 .. 此原则和里氏代换原则氏相辅相成的 , 两者都是具体实现 " 开 - 闭 " 原则的规范 .. 违反这一原则 : 就无法实现 " 开 - 闭 " 原则 .. 先来看看什么是合成 , 什么是聚合 .

      什么是合成?
     合成: 是指一个整体对依托他而存在的关系 , 例如 : 一个人对他的房子和家具 , 其中他的房子和家具是不能被共享的 , 因为那些东西都是他自己的 .. 并且人没了 ,  这个也关系就没了 .. 这个例子就好像 , 乌鸡百凤丸这个产品 , 它是有乌鸡和上等药材合成而来的一样 .. 也比如网络游戏中的武器装备合成一样 , 多种东西合并为 一种超强的东西一样 ..
      
      什么是聚合?
      聚合: 聚合是比合成关系的一种更强的依赖关系 , 聚合是一个整体对个体的部分 , 例如 , 一个奔驰 S360 汽车 , 对奔驰 S360 引擎 , 奔驰 S360 轮胎的关 系 .. 这些关系就是带有聚合性质的 .. 因为奔驰 S360 引擎和奔驰 S360 轮胎他们只能被奔驰 S360 汽车所用 , 离开了奔驰 S360 汽车 , 它们就失去了存 在的意义 .. 在我们的设计中 , 这样的关系不应该频繁出现 .. 这样会增大设计的耦合度 ..
      明白了合成和聚合关系, 再来理解合成 / 聚合原则应该就清楚了 .. 要避免在系统设计中出现 , 一个类的继承层次超过 3 次 .. 如果这样的话 , 可以考虑重构你的代码 , 或者重新设计结构 .. 当然最好的办法就是考虑使用合成 / 聚合原则 ...

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

     接口隔离法则: 这个法则与迪米特法则是相通的 , 迪米特法则是目的, 而接口隔离法则是对迪米特法则的规范 .. 为了做到尽可能小的耦合性 , 我们需要使用接口来规范类 , 用接口来约束类 . 要达到迪米特法则的要求 , 最好就是实现接口隔离法则 , 实现接口隔离法则 , 你也就满足了迪米特法则 ...
    
 
       如果你能看这里, 说明你已经对这些原则了有了感性的认识 .. 这些原则是设计模式的核心 , 如果不能充分理解这些原则 , 是很难理解好设计模式的 ..

      如果第一遍看不懂, 没关系 , 请 反复揣摩, 细读每个字 , 每句话 .. 对于这些原则, 我也是看了 N*N 遍才明白的 ( 这期间也没任何人指点过我 , 更每人讲的这么细 , 奖励自己一下先 , 汗啊 ).. 我推荐看完原则之后 , 请看设计模式 , 看两三个模式 , 然后理解一下 , 自己动手把模式实现出来 , 再回头来看原则 , 你会感觉 , 你的模式一定是满足了其 中的某些原则 !! 这是必然的 !! 只要你理解了原则 , 设计模式不难理解 .. 就好比 , 有了内功基础的你 , 再来学习刀 , 剑 , 枪这些武器的时候 , 要比那些直接学习 刀 , 枪 , 剑的人 , 快很多 , 效果也好很多 ...