【DM】设计模式总括-原则篇

写在前面的

   感谢上天又给了我一次学习设计模式的机会，正是这次的系统学习，可以说让我领略到了设计模式的真谛，23个设计模式已经在我脑海中已经变得那么的亲切，也让我觉得对这23个设计模式可以融会贯通，真的是一件非常非常值得高兴的事情。
   说到这里，自己在之前总结的几个实模式就已经太过于LOW了，只是总结出了形，并没有总结出神，接下来就通过三个方面来对我眼中“非常简单”的设计模式来进行一次宏观而又细致的总括。

设计模式的灵魂

三兄弟

   回想起第一次看设计模式的时候总是对这三个概念嗤之以鼻，觉得无非就是一种格式，只要大家遵从就OK了，但是现在觉得，这三个原则简直就是“天律”一般，把设计模式的灵魂全部都淋漓尽致的体现了出来。

开放-封闭

• 对扩展开放，对修改封闭

• 总的来讲，开放封闭原则在一定程度上针对的是单个的CLASS。但实际上体现的是在整个设计模式中对类模块的耦合度和内聚度的把控。

依赖倒转

• 高层模块不应该依赖底层模块。其二者都应该依赖于抽象。同时，抽象不应该依赖于细节，细节应该依赖于抽象。

• 这一条规则如果需要具体体现的话，那就是在最后的实例化阶段了，通过设计模式画出来UML的类图只是体现在了类与类之间的逻辑关系，并不能实际表现出依赖倒转，注意，如果两个类之间是继承关系，父类为抽象类，子类中覆盖父类方法，像这样的结构并不能说明依赖倒转原则。就像我开始说的，依赖倒转原则是到了我们的功能模块或者功能类将要使用的时候才会体现出来。举一个最最简单的例子就是声明父类实例化子类。

迪米特

• 如果两个类不必彼此直接通信，那么这两个类就不应当发生直接相互作用。如过其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

• 我相信，看到这里，你就会觉得这三个原则是一种层层递进的模式。正因为我们有了“开放封闭”才会使得“依赖倒转”进行的非常彻底，也正是因为有了“依赖倒转”才有了“迪米特”的可能。为什么这么说呢？回想一下我们在设计模式中经常看到一种现象，那就是“组合”和“聚合”，具体一点我们可以用“桥接模式”(或者组合模式，或者职责链，策略，状态，whatever)中的聚合关系来简单阐述一下，我们的父类（或者是抽象类）在与子类产生聚合或者组合关系时是为了什么？只是单单觉得我的子类可以扩展么？

• 不，并不是这样，如果是这样，那直使用泛化就好了，为什么就偏偏运用了关联呢？说到这里，我们的关键点就有了，正是我们有了父类（或者抽象类）这一个“规则”，使得继承它的子类都具有相同的“属性”或者相同的“规则”，使得继承了这个父类（或抽象类）子类们都属于同一个“品种”，这样无形之间就让子类之间的调用产生了非常“舒服”的感觉。仔细观察设计模式中的代码，我们会发现，几乎所有的模式中都会存在构造函数，也正是这样的构造函数，让子类在调用同属于一个父类的其他子类的时候，想要添加什么样的同类都可以变成现实，这就是“舒服”点，这也正是我认为迪米特法则的精髓所在，也就是借助于父类（或抽象类）的同属关系去解决调用问题。

• 注：并不是不同类之间不能产生调用，只是因为如果两个不同类之间需要借助第三个类产生关联，那么就需要在第三个类中写入一些繁杂的交互，这样不如在同属性的类中调用来的方便。这也是为什么设计模式非常强调依赖倒转的原因所在。

总结

   为了使文章看起来非常的简短，我们的原则篇先总结到这里，接下来的几篇文章，我会拿出23个设计模式中一些非常典型的例子来具体说明，设计模式的学习如何之简单！