最近在学习设计模式，把它们写进博客记录下来，以备查阅。
学习设计模式我们要从以下几点入手：
设计模式是什么？
为什么要使用设计模式？
设计模式需要在什么场景下使用？
设计模式有哪些使用原则？
设计模式有哪些类型？
1、设计模式是什么？
先看度娘给的解释：
：
一目了然哈。试想我们写出的代码，别人看不懂或者是过了一段时间自己也看不懂了，扩展性不好，更不利于维护，这该多么糟糕。
设计模式，度娘简介：设计模式（Design pattern）代表了最佳的实践，通常被有经验的面向对象的软件开发人员所采用。设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。设计模式是一套被反复使用的、多数人知晓的、经过分类编目的、代码设计经验的总结。
2、为什么要使用设计模式？
上面已经给出了答案，代码重用度高、易读性好、代码可靠性高。个人理解代码简洁明了，易扩展维护，高端大气上档次哈
3、设计模式需要在什么场景下使用？
每个模式使用场景各有不同，之后会逐一简介。使用模式最好的方式是：把模式装进脑子里，然后在你的设计和已有的应用中，寻找何处可以使用它们。以往是代码复用，现在是经验复用。
4、设计模式的使用原则
设计模式共有六大原则，贴上一张度娘图，一目了然
介绍下六大原则的概念：
开闭原则（Open Close Principle，OCP）开闭原则的意思是：对扩展开放，对修改关闭。
在程序需要进行拓展的时候，尽量不去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类,而抽象化是开闭原则的关键。
里氏替换原则（Liskov Substitution Principle,LSP）所有引用基类（父类）的地方必须能透明地使用其子类的对象
里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。
依赖倒转原则（Dependency Inversion Principle,DIP）抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程
依赖倒转原则要求我们在程序代码中传递参数时或在关联关系中，尽量引用层次高的抽象层类，即使用接口和抽象类进行变量类型声明、参数类型声明、方法返回类型声明，以及数据类型的转换等，而不要用具体类来做这些事情。为了确保该原则的应用，一个具体类应当只实现接口或抽象类中声明过的方法，而不要给出多余的方法，否则将无法调用到在子类中增加的新方法。在引入抽象层后，系统将具有很好的灵活性，在程序中尽量使用抽象层进行编程，而将具体类写在配置文件中，这样一来，如果系统行为发生变化，只需要对抽象层进行扩展，并修改配置文件，而无须修改原有系统的源代码，在不修改的情况下来扩展系统的功能，满足开闭原则的要求。
在实现依赖倒转原则时，我们需要针对抽象层编程，而将具体类的对象通过依赖注入(DependencyInjection, DI)的方式注入到其他对象中，依赖注入是指当一个对象要与其他对象发生依赖关系时，通过抽象来注入所依赖的对象。常用的注入方式有三种，分别是：构造注入，设值注入（Setter注入）和接口注入。构造注入是指通过构造函数来传入具体类的对象，设值注入是指通过Setter方法来传入具体类的对象，而接口注入是指通过在接口中声明的业务方法来传入具体类的对象。这些方法在定义时使用的是抽象类型，在运行时再传入具体类型的对象，由子类对象来覆盖父类对象。
接口隔离原则（Interface Segregation Principle,ISP）使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口
使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。
迪米特法则（Law of Demeter,LoD），又称最少知道原则。
最少知道原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。
单一职责（Single Responsibility Principle,SRP）
一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因
单一职责原则告诉我们：一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验
以上只是概念的阐述，至于具体实例的实现可以参考以下链接
https://blog.csdn.net/LoveLion/article/category/738450/7
https://www.cnblogs.com/dolphin0520/p/3919839.html
5、设计模式的类型
GOF总结出来23中设计模式，当然发展的目前为止还有一些其他的模式，这里暂时就研究了哈。23种模式分为三大模式：创建型、结构性和行为型模式。继续盗用度娘图片，嘿嘿。
上图中有点小瑕疵，这里更正下，图标行为型中11多打了一个式字，实为责任链模式，说职责链模式亦可。
至于每个设计模式介绍，用法场景，之后我们再介绍。下面用一个图片来描述一下设计模式之间的关系：
以上即为设计模式的简介了，让我们回顾下本文介绍了哪些东西：
设计模式的概念、为什么使用设计模式、设计模式应用的场景、设计模式应遵循哪些原则以及设计模式的类型。
附上刘伟老师设计模式教学级讲解链接
https://blog.csdn.net/LoveLion/article/details/17517213
下一篇博文从最常用也是用的最多的 单例模式说起，待续...