设计模式(001) 开启设计之旅

设计模式--开启设计之旅

我的设计模式之旅：

     “身体和灵魂，总有一个在路上”，有的人旅行，有的人看书，还有些人在旅行中写出启迪人心的好书来，身体在路上赋予了灵魂的力量。我的设计模式之旅，与你、与我，能带来什么呢？抛开遥远深邃的美丽传说，是为了感谢Java OO给了我新的生命力，是为了将自己的所学贡献给社区，是为了给后生多点上一盏灯，是为了让自己的灵魂保持活力，最后，也是最重要的，为了中国的软件行业不要多出我这个码农。转行本来是要冒风险，要转身，为什么不华丽转身呢？既然转身，为什么不昂首挺胸走下去呢？既然走下去，为什么独自一人呢？So，我自掏腰包，买了车票，跟随GOF，约上OO先生，开始我们的远行。

车票概览：

     列车：Java OOD 冲锋号

     座位：5车13座

     乘客：YSJIAN

     同伴：OO先生

     导游：GOF

     出发地：对象村

     目的地：模式村

     途径：单例-->工厂方法-->抽象工厂-->模板方法-->策略-->外观-->适配器-->观察者-->状态-->装饰器-->代理-->建造者-->命令-->桥接-->组合-->备忘录-->迭代器-->享元-->中介者-->原型-->访问者-->解释器-->责任链

    提示：如遇特殊情况，途径站点会有所波动，请安心享受旅途的风景。

---

旅行指南：

<温馨提示：快速浏览指南标题能更快带您进入轻松的旅行状态>

 P1:唯一不变的是变化（封装变化）

抽取出应用中可能需要变化的地方，把它们独立封装起来，以免与那些不需要变化的代码混在一起。封装了系统变化的部分，后期的修改和扩展对不变的稳定的部分不会造成影响。修改只需要针对独立出来的变化部分代码进行修改，这样的修改局部集中，引起的不经意的后果变少，使得维护变得简单容易。

 P2:接口、抽象，好榜样（针对接口而非实现编程）

针对接口编程，而不是针对实现编程。什么是接口呢？通用的术语，它是与其他实体(一个方法、一个类、一个模块或者一段程序)进行交互的方式，可以理解成一种行为规范或者约定。面向接口编程，旨在让类之间的交互发生在高层次的抽象、接口上，关注之间的契约和规范，而不需要关心底层的实现细节，让客户以统一的接口去使用，让客户从你的具体实现中解耦。后期针对实现细节的修改不会被客户感知到，只需要依然要遵循约定的接口规范，扩展的时候就更加灵活了，只需在原来的接口规范上进行扩展而不影响其他的地方。

 P3:扩展搏击赛（组合优于继承）

多用组合，少用继承。继承属于白箱复用，父类的内部细节对子类可见，而组合属于黑箱复用，被组合的对象依然能够保持自己的封装性。继承让我们较方便地改变被复用的实现，当一个子类重定义一些而不是全部的操作的时候，也能影响其他所继承的操作（钩子方法）。但继承在编译的时候就确定了，无法在运行时改变从父类继承的实现，一旦后期父类有所变化，就会影响其所有的子类，有些变化对于子类来说是不必要的甚至是错误的。而组合能够让被组合的对象运行时动态替换以提高系统的灵活性，使用对象组合有助于保持每一个类被封装并被集中在单个任务上，使得系统的类和继承层次保持在较小的规模，避免了继承中造成的类泛滥现象。某些情况下，使用继承使得创建新的构建比组装旧的构建来的容易，所以需要组合和继承一起使用了。

P4:虎父无犬子（里氏代换原则）

里氏代换原则强调任何时候子类必须能够替换掉父类，一个应用如果使用的是一个父类，那么一定可以使用该类的子类，而且应用察觉不出父类和子类对象的区别，替换后程序的行为没有发生变化 。只有当子类能够替换掉父类，软件的行为没有收到影响时，父类才能真正地被复用，而子类也能够在父类的基础上增加新的行为，这是对开 /闭原则补充。

P5:倒着看，世界更美（依赖倒转原则）

依赖倒转原则思想有两点： a. 依赖抽象，不要依赖具体，不能让高层组件依赖低层组件，两者都应该依赖于抽象 ；b. 抽象不应该依赖细节，细节应该依赖抽象 。假设你实现一家蛋糕店，蛋糕店负责对蛋糕进行准备、切割、成型、点缀、装盒，为了满足众多的用户的需求，需要生产各种样式和口味的蛋糕，如水果蛋糕、奶油蛋糕、巧克力蛋糕等，那么你第一件事是想到的从顶端开始，蛋糕店 —>生产各式各样的蛋糕，那么蛋糕店就需要全部依赖这些具体的蛋糕类，导致了过度依赖。不妨倒过来想，各种口味风格的蛋糕都是蛋糕，可以让他们共享一个Cake接口，这时我们不从顶端开始，而是从Cake开始，抽象化一个Cake接口后，回头重新设计蛋糕店，这时蛋糕店只需要认识Cake接口，不需要理会具体蛋糕类，达到了高层组件依赖抽象的目的。另外辅助一个工厂类将具体的蛋糕从蛋糕店里取出，这些具体的蛋糕类也只能依赖 Cake接口了，达到了细节依赖抽象的目的，实现了松耦合。

P6:多而不专真不好吗（最少知识原则）

最少知识原则告诉我们，在设计中，不要让太多的类耦合在一起，以免后期修改系统中的一部分，影响到其他部分，如果过多的类之间相互依赖，将会让系统变得易碎难以维护。在一个对象方法中调用属于下面四种范围内的方法： a.该对象本身；b.被当做方法参数传进来的对象； c.方法内部实例化的对象； d.该对象的任何组件（成员变量） 。对其他类知道太多必然会导致耦合过度，如果一个类专们针对以上四种范围的方法进行调用，那么它就是专一的。试想你是一名新来的员工（规模较大），行政部领导S派A给你配置的电脑出了点问题，但是你去行政部没有找到A，这是你请求其他的行政部的同时如B、C、D等帮忙解决，但是他们都不愿理睬你，因为你跟他们不熟，何况大家都有自己的工作，苦恼的你一上午都没有搞定电脑，快下班那会儿，你见到了 S，问题反馈给S后，S：“ 那谁谁谁，你帮忙把这位新同事 E的电脑解决一下”，午休一觉醒来你的电脑已经好了。

最少知识原则原名得墨忒法则，取名最少知识一来名字更直接，二来法则给人的感觉是强制的，而面向对象中没有任何原则是法律，所有的设计原则只在对设计有帮助的情况下遵守，所有的设计都会在抽象和速度之间取舍，在空间和时间之间权衡，原则提供了方针，但核心是对所需要实现的业务的建模。

P7:分工明确，各司其职（单一职责原则）

分工明确，各司其职在企业管理中也是一个重要的原则，在软件中，单一职责原则强调类的职责不要过多，就一个类而言，应该仅有一个引起它变化的原因 。如果一个类承担了过多的职责，相当于将这些职责耦合在一起了，一个职责的变化可能会削弱或者妨碍这个类完成其他的职责，这种耦合会导致设计变得脆弱，当变化发生时，设计会遭受意想不到的破坏。软件设计要做的许多内容，就是发现职责并把那些耦合在一起的职责进行分离，这里提供一个衡量一个类存在过多职责的方法： 如果你能想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责 。当然这不是一件容易的活，由于我们的大脑很习惯看着一大群行为，然后将它们集中在一起，尽管他们可能属于两个或者以上的不同的责任，那么这就需要努力不懈地检查你的设计，随着系统的成长，随时观察有没有迹象显示某个类改变的原因超出一个。实际编码中，一个衡量类的内聚性的标准是，在一个类的内部，如果各个方面都紧密相关，并且都在这个类的唯一职责范围之内，所以类的职责越单一，类的内聚性越强，这也是我们设计的一个目标驱动力之一。

P8:喂，好莱坞的电话（好莱坞原则）

好莱坞，一个让许多俊男靓女欲罢不能的地方。在通往成功的路上，有谁不愿意通过捷径而一炮而红，在这之中影视声色是许多人会尝试的方式之一。

不过，好莱坞不是一般的场所，它不是什么阿猫阿狗都可以进入的地方，他们不缺少俊男靓女。因此，如果你有一双俊俏的脸庞，你不要在他们面前显摆，他们不在乎。你可能会说，我的演技非常棒，哦，没用，这样的人在好莱坞遍地都是。

梦想进入好莱坞的人们，你们不要找好莱坞。那怎么办呢？答案是，让好莱坞来找你！

别调用我们，我们会调用你。当高层组件依赖低层组件，而低层组件又依赖了高层组件，高层组件依赖了边侧组件，边侧组件依赖了低层组件，依赖腐败就发生了，导致了系统无法被人读懂。Spring中IOC，控制反转就是遵循好莱坞设计原则的典型例子，Spring是一个框架(Framework)级别的容器，几乎所有的Framework都遵循好莱坞原则，引入这些Framework的好处是，用户只需要关注自身的业务实现，高层Framework会根据配置自动调用用户的具体业务代码，而用户无需知道Framework的工作，业务代码不应该去调用Framework的逻辑。即高层调用低层，低层不应该调用高层。

好莱坞原则强调高层对低层的主动作用，即低层应该只管好自己的工作，而高层自有它自己的工作，在不需要到某个低层的时候，高层并不会调用到这个具体低层，低层永远不需要向高层作出表示，说它需要被调用，低层逻辑永远不要涉入高层的实现，而只要高层通过某个逻辑去涉入低层的实现，也即低层应不要调用高层，只有高层才会去调用低层，这才是合理的，我们应尽量避免向上调用和相互调用。

美丽的风景始终在后面等着您......