闲聊设计模式篇第一章 设计模式的原则及理解

闲聊设计模式篇

第一章 设计模式的原则及理解

---

前言

接触设计模式之前，全凭经验与总结，接触之后发觉已经有前人为你总结了许多可用的东西，设计模式应该说是一个程序员进阶的必经之路，我也是抱着学习的心态，将经验，查阅的书籍资料，老师所教的东西，收集收集，整理整理，既是为自己后续翻阅用，也希望对读者有点帮助。

---

一、设计模式的定义与模式设计的原则

定义
设计模式是指在软件开发过程中，经过验证的，用于解决在特定环境下重复出现的，特定问题的解决方案。

模式的原则

1、依赖倒置原则
（1）高层模块不应依赖底层模块，二者都应依赖抽象
（2）抽象不应该依赖于具体实现，具体实现依赖抽象

这个原则怎么理解呢，举一个例子，在我的另一篇博文中提到内存模型的时候，有说到内存模型就是一种抽象，它是为了解决开发过程中，开发者不应因CPU不同，就需要去实现不同的多线程代码，这里高层模块就是多线程代码，底层模块就是CPU（或者说CPU相关的操作集），CPU操作集的实现不可能因为你上层要做多线程，就不做指令的乱序，你上层多线程不可能因为你每个CPU的指令乱序实现不同我跟着多线程实现也不一样，因此抽象出一层内存模型，提供了内存屏障相关的实现，隔离了高低层模块。抽象不依赖于具体实现是说，我们是要都依照内存模型的编码要求来开发，而不是你开发是一个样，我开发是一个样，抽象会随着我们不同而改变。
2、开放封闭原则
一个类应该对扩展开放，对修改关闭

字面理解即可，比如我们一个基类，我们扩展可以通过继承，在子类中进行扩展，但尽量避免对类本身做修改来达到我们的需求。
3、面向接口编程
（1）不将变量类型声明为某个特定的具体类，而是声明为某个接口；
（2）客户程序无需获知对象的具体类型，只需要知道对象所具有的接口
（3）减少系统中各部分的依赖关系，从而实现高内聚，松耦合的类型设计方案

4、封装变化点
（1）将稳定点和变化点分离，扩展修改变化点。让稳定点和变化点的实现层次分离
关于这一项，必须要强调的就是稳定点和变化点的分离，模式设计的思路，基本上都是要先去区分稳定点和变化点，如果没有变化点，或没有稳定点，就没有用设计模式的必要，区分出稳定点和变化点之后，再去抽象出隔离层，或是封装变化点，或封装稳定点。
5、单一职责原则
一个类应仅有一个引起它变化的原因
6、里氏替换原则
子类型必须能够替换掉它的父类型，主要出现在子类覆盖父类的实现，原来使用父类的程序，可能出现错误，覆盖了父类方法，却没实现父类方法的职责
7、接口隔离原则
（1）不应该强迫客户依赖于他们不用的方法；-----对客户不用的接口，不开放出去
（2）一般用于处理一个类拥有比较多的接口，这些接口设计到很多职责
8、对象组合优于类继承
继承耦合度高，组合耦合度低。

二、什么时候再去使用设计模式，如何确定要使用的设计模式，为什么要学设计模式

一般情况下，如果能明确找到以下的其中一点，都可以使用设计模式

• 系统的关键依赖点
• 能找到明确变化点
• 能明确复用方向
• 对需求变化方向熟悉
  以个人经历举例，我最开始做项目开发的时候，当时的需求很少，需求后续的变化方向很不明确，项目组更希望的是看到一个产品demo，这种情况下没办法去用设计模式的，即使勉强总结出了当前的功能点，分离了稳定点和变化点，到了中后期需求的爆发式增加，很有可能导致软件的重构，除非你一开始就预测到了后续需求会怎样增长，但做设计模式总结有没有用呢，有用，能让你根据当前的需求情况，提供一种思路，让你的软件即使重构，能复用的模块也尽可能多。
  设计模式是从重构中来的这点我很认同，虽然已经有很多种设计模式，但现实的情况往往比已总结的迥异的多，我们也必然会遇到一些情况下头脑里没有熟悉的设计模式可套用，所以模式设计原则尤为重要，遵循模式设计原则的开发，其实也相当于在为你当前的项目去摸索一个设计模式，而使用模式设计原则的过程中，也基本上都无法避免代码重构，可能一开始对外封闭的接口，因需求的变动不得不开放，可能一开始只满足了两个模式设计原则，现在发觉可以调整使代码满足更多的模式设计原则，这都是很常见的。

所以我们学习设计模式的目的，并不是为了去死记硬背它们，而是在学习已有的设计模式的过程中，理解模式设计的原子，能在已使用的设计模式中写扩展，能在后续的工作中面对复杂需求，尽可能抽象出已有的设计模式，能在重构中开发自己的设计模式。