设计模式的思想

现在框架能提供的服务越来越丰富，工程师在处理的时候，会越来越关心框架的逻辑，很多工程师可能只考虑如何使用框架，而不去考虑框架为什么这样设计，这也是导致很多工程师做了很久的开发，依然还是在做开发的原因。

俗话说：数据结构，算法和设计模式是工程师的三件法宝。熟练掌握和使用是在以后的工作和学习过程中可以做到事半功倍，也是工程师进阶的必要条件之一。我们就从三件法宝之一的设计模式开始我的第一篇技术博客。

（写这篇文章之前，我有很多担忧，我只是平凡的互联网从业者中的一员，我担心写的不够好，误导读者；但是我鉴定写这篇文章就像我第一篇文章写的，主要是交流学习~）

为什么使用设计模式？

我们举个例子：小明是一名产品经理，小刚是一名开发人员，有一天小明找小刚沟通
小米：我有一个简单的需要（嗯，简单的需求~），我想发一篇文章，用户打开应用的时候就能看到;
小刚：简单，安排~

小刚一顿操作，半个小时候后，
小刚：小明，开发完了，你测试下~

五分钟后，小明测试完
小明：我想加一个推送的功能，文章发布之后，推送给用户看~
小刚：安排~（内心OS:早干嘛了）

小刚又是一顿操作，半个小时候后，
小刚：小明，功能加完了，你再测试下~

五分钟后，小明测试完了
小明：小刚，推送可以用，但是我觉得不完整，我想。。。
这时候小刚拿出了40m的大刀，说道：你知道我改这个功能需要改多少代码吗？你能不能把逻辑想清楚~

对话END~~~~

我觉得这例子是现实中比较常见的例子，这说明了代码的可扩展性差、复用性差，耦合度高等问题，这时候就需要用到设计模式。

什么是设计模式？

不是牛顿说的的一句话：“如果我看得更远一点的话,是因为我站在巨人的肩膀上”。

设计模式（Design Pattern）是一套被反复使用、多数人知晓的、经过项目实战的开发经验的总结（对，就是总结，踩在巨人的肩膀上）。并且这套总结，可以实现代码代码的高可扩展性、高复用性和松耦合等功能。

掌握设计模式之后，将提高一下能力：
1.代码能力的增强；
2.节省沟通成本，一句话：这个功能使用xxx模式实现的，你你应该明白的程序的执行逻辑了；
3.阅读源码能力的提高，大师就是大师，这个模式的我明白；
。。。。。。。

设计模式的原则

设计模式的原则也是面向对象编程的原则，面向对象编程和面向过程编程主要的是编程思想的不同：面向过程是对实现过程进行逻辑编程；面向对象是对实现过程中所用的对象的组合（有点绕~）。

举个栗子：
小明要从车站买票去北京~
面向过程思想：小明要先去车站 -》买票 -》上车 -》 下车
面向对象思想：把过程中使用的工具抽象成对象：车站 车票 车，然后把这些对象进行组合，小明就到北京了。

三大基本特性：封装，继承，多态

封装

把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。一个类就是一个封装了数据以及操作这些数据的代码的逻辑实体。

继承

它可以使用现有类的所有功能，并在无需重新编写原来的类的情况下对这些功能进行扩展。 通过继承创建的新类称为“子类”或“派生类”，被继承的类称为“基类”、“父类”或“超类”。继承的过程，就是从一般到特殊的过程。

多态

一个类实例的相同方法在不同情形有不同表现形式。多态机制使具有不同内部结构的对象可以共享相同的外部接口。

五大基本原则

单一职责原则SRP(Single Responsibility Principle)

是指一个类的功能要单一，不能包罗万象。如上面例子，车站就负责卖票和上下车，不能具有车行驶的功能。

开放封闭原则OCP(Open－Close Principle)

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。还是上面的例子，现在我要增加坐飞机去北京的功能，在增加这个功能的时候，不能影响坐车去北京（对扩展是开放的）；如果小米觉得车站的服务太差，想要增加车站工作人员的数量，那是不可能（对修改是封闭的）。

里氏替换原则LSP(the Liskov Substitution Principle LSP)

子类应当可以替换父类并出现在父类能够出现的任何地方。还是上面的列子（假设同学们已经理解继承的概念了），小明想这次做火车去北京，下次坐汽车去北京，火车站和汽车站都继承了车站这个基类，那么小明就可以选择汽车和火车进行出行了，而不应该只限于火车或者汽车。

依赖倒置原则DIP(the Dependency Inversion Principle DIP)

具体依赖抽象，上层依赖下层。假设B是较A低的模块，但B需要使用到A的功能，这个时候，B不应当直接使用A中的具体类：而应当由B定义一抽象接口，并由A来实现这个抽象接口，B只使用这个抽象接口：这样就达到了依赖倒置的目的，B也解除了对A的依赖，反过来是A依赖于B定义的抽象接口。通过上层模块难以避免依赖下层模块，假如B也直接依赖A的实现，那么就可能造成循环依赖。

迪米特原则LOD(Law of Demeter LOD)

迪米特法则又叫做最少知识原则（Least Knowledge Principle, LKP）

由于每个对象尽量减少对其他对象的了解，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

接口分离原则ISP(the Interface Segregation Principle ISP)

模块间要通过抽象接口隔离开，而不是通过具体的类强耦合起

设计模式的分类

范围 创建型 结构型 行为型

范围	创建型	结构型	行为型
类	Factory Method（工厂方法）	Adapter(类) （适配器）	Interpreter（解释器） Template Method（模版方法）
对象	Abstract Factory（抽象工厂）Builder（建造者）Prototype（原型）	Bridge（桥接）Composite（组合） Decorator（装饰者） Facade（外观）Flyweight（享元）Proxy（代理）	Chain of Responsibility（职责链） Command（命令） Iterator（迭代器） Mediator（中介者） Memento（备忘录） Observer（观察者） State（状体） Strategy（策略） Visitor（访问者）

没有哪种模式是完美的，实际开发过程中，我们需要根据不同的需求来使用相应的模式，这样才能体现出高内聚，低耦合的好处；还是开头说过的，设计模式是经验的总结，熟练使用设计模式不仅仅能提高自己的效率，熟能生巧，在现实生活也有意义。