设计模式的思想

如今框架能提供的服务愈来愈丰富，工程师在处理的时候，会愈来愈关心框架的逻辑，不少工程师可能只考虑如何使用框架，而不去考虑框架为何这样设计，这也是致使不少工程师作了好久的开发，依然仍是在作开发的缘由。

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

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

为何使用设计模式？

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

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

五分钟后，小明测试完
小明：我想加一个推送的功能，文章发布以后，推送给用户看~
小刚：安排~（心里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（访问者）

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