浅读《大话设计模式》————11、无熟人难办事？——迪米特法则

迪米特法则（LoD），如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者调用。[J&DP]

本法则强调的是，在类的设计上，应该尽量保证类之间的松耦合。类之间的关系不应该必须是直接调用的，而应该是通过抽象来实现各自的功能。就如同人际关系办事情，如果是必须要针对个人，那么没有熟人或者熟人不在，那就办不成了？这种体制显然不好！比如，希望政府办的事情，应该不需要知道要谁来处理，只是统一向政府提个需求，然后他们内部派人处理好！迪米特法则，最少知识原则。

浅读《大话设计模式》————10、模板方法模式

模板方法模式，定义一个操作中的算法的骨架，而将一些步聚延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定不聚。[DP]

模板方法的优点：通过把不变的行为放到父类，并在父类中提供模板方法，父类中还可能内部调用一些细节函数，但是这些细节函数是虚函数，由不同的子类实现不同的具体功能。这样子类完成特定的行为，但是不需要重复的代码。

好了，简单的模板方法模式，同样是面向对象中继承和多态的组合运用。学好了！

浅读《大话设计模式》————9、简历复印——原型模式

原型模式，用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。[DP]

原型模式其实就是从一个对象再创建另外一个可定制的对象，而且不需知道任何创建的细节。看到这些说明，我想这是不是可以理解为c++中的拷贝构造函数呢？这可能是需求中最常见的模式了。

如果从这个角度理解，无疑的，这个模式就可以通过了。只是他告诉我们：设计的时候考虑批量生产的情况，所以需要提供复制的方法。至于文中所讲的浅复制和深复制，好像C#中才考虑这个问题，c++中指针引用等是必须要特定处理的。学好了！

浅读《大话设计模式》————8、雷锋依然在人间——工厂方法模式

简单工厂模式、工厂方法模式，这两者的区别我想顾名思义！前者讲的是这个模式用到一个简单工厂，但是后者强调的是工厂方法，其实意思就是该模式中工厂设计很重要。

其实理解了简单工厂，基本上只要再稍微看一下工厂模式的设计，就很容易理解这两个模式。不过，似乎工厂方法模式是简单工厂模式的改进版，简单工厂没有存在的必要。但是事实并非如此，在扩展不经常的时候，一个简单工厂就可以了。但是要是经常有相似功能的扩展需求，那么工厂方法模式就要有价值一些。

在代码形式上，简单工厂模式的最大优点在于工厂类中包含了必要的逻辑判断，根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。但是，工厂方法是把简单工厂的内部逻辑判断移到了客户端代码来进行。所以，想要增加功能，就同时需要修改客户端代码。但是这样代码结构还是很清晰的，所以两者各有千秋！

浅读《大话设计模式》————5、会修电脑不会修收音机？——依赖倒转原则

电脑比收音机简单吗？为什么拆开两者，很明显，收音机看起来还要比电脑更复杂呢？原来，好的架构好的设计在哪里都是通用的！电脑各部件缺一不可，但是绝不是只针对某一个或者某一类产品，所有不同产品的厂商都只服从一个统一的标准，这样，我们就看不出电脑中哪一个是高层了。CPU？内存？或者主板？。。。都不是，谁也不依赖谁，依赖的是一个统一的接口标准！

依赖倒转原则：抽象不应该依赖细节，细节应该依赖抽象。具体到一个实际问题编程，应该是定义好的接口，这个接口不属于哪一个具体的东西，应该是一个高层的抽象，然后就是针对接口编程，而不要对实现编程。

讲到这里，似乎世界的一切问题都迎刃而解，一切显得是那样的轻而易举！慢！一定不要自负的轻视对手，好，谁都很听话的服从这个抽象接口，那么这个抽象接口怎么来？一切都在变，难道这个抽象类就是可以违背这个哲学上绝对真理的特例家伙？他可能自身都要不停的变！完了，到哪里去找这样一根标尺呀？

标尺也是自己定义的！无非是会需要随实际情况变化吗？不要忘了，我们已经学会的绝技——开放—封闭原则。我们保证提供基本功能的接口不变，实际需求增加时，只要做开放扩展即可，面向对象的继承能帮助我们找到正确适用实际问题的方法，问题不就解决了吗？恩，这样设计总结出统一的抽象接口或者抽象类是满足我们的需求的，不过，还有关键的一点，这一系列类必须要满足一个原则：里氏代换原则：子类型必须能够替换掉他们的父类型。这个原则在许多别的情况下，并不一定是完全满足的，但是此处用做标尺的抽象类，必须要满足！子类可以扩展做更多的事情，但是父类已经定义好的接口子类必须有实现，并且也必须是做一致的事情。

依赖倒转原则说明了：好的面向对象设计不应该是依赖具体实现中的那一部分，应该是针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口。那样，高层、底层的改变都不会导致另外一部分要做变化了。

从北京去纽约喽，;-)，还有陆路还要海洋，哈哈，变化再大我也不管，因为我做的是飞机！不过，你要是愿意先客车再渡轮也可以的哦~都是交通工具的抽象嘛！应该不会还有那个大侠想着依赖道路的，先穿跑鞋再换个泳衣去的吧~

浅读《大话设计模式》---------------4、考研求职两不误----开放-封闭原则

开放—封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。[ASD]。这个原则有两个特征：对于扩展是开放的，另一个是说对于更改是封闭的。

本原则经过作者精辟的阐述，马上就让我们在哲学上对一些问题的看法豁然开朗：看起来两个完全抵触的东西，利用扩展与封闭原则就能很好的解决。什么东西必须关闭，什么东西可以扩展？主权和业绩是必须关闭修改的，但是制度却是可以扩展开放的！难道这仅仅是一种计算机理论吗？这简直是处事之道！

如何应对变化？——除非你足够强大，所有的人和事都无条件的服从你的，否则就需要面对无法预料的变化。事实上，对未来变化的估计和处理能力正是智慧的体现。好像离程序设计越来越远了哦~言归正传，既然变化是无法避免的，那么对已有的机制进行对应的修改也是必须的（真的有“以不变应万变”么？）。所以，“绝对的修改关闭是不可能的。无论模块是多么的‘封闭’，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化[ASD]。”

“在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化[ASD].”这里同时也反映了一个问题：要架构好的程序，我们需要善于分析程序的变化，善于总结善于抽象！当遇到问题了，我们应该思考这一类问题，并作出抽象改善程序的架构，提取出真正的封闭的和开放的部分。

大鸟的总结：“开放—封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要[ASD]。”

很好，从本设计模式学到了很多很多，远远超过了程序设计的范畴！哈哈，考研的例子我觉得也很合适嘛。全力以赴是必须的，两手准备也是一种灵活。只要别忘了自己当前的重点——就像快乐一样，得到成功的目标是关闭的，但过程是开放的！

浅读《大话设计模式》----------------3、拍摄UFO------单一职责原则

       这个模式应该是最容易理解的一个模式了。不过解释意义还是比较有深度的：就有一个类而言，应该仅有一个引起它变化的原因[ASD]。职责越单一，功能就越独立。也就没有复杂度，就更好维护，也更利于复用了。

       作者对这个模式的运用和解释已经很清楚了“软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离[ASD].其实要去判断是否应该分离出类来，也不难，那就是如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD],就应该考虑类的职责分离。”