什么是设计模式（Design Pattern）？
在我个人看来，模式一般是指内容会有边界（Border）或有比较固定内容（Fixed Content）的指导性东西，类似于路走多了就进而形成了路，这个路是有明显边界的和指导性的，所以个人理解的设计模式是特定问题的常用指导解决方案。
设计模式是高层次的解决方案，它要求个人在碰到问题时，不要过多关注问题的细节，将问题泛化和抽象化剥离出问题的核心，进而匹配看是否符合众多设计模式的使用场景而选用。所以设计模式描述的是：在各种情况下要选择什么样的方案来解决问题。
项目中合理地运用设计模式可以完美地解决很多问题，每种模式都在描述一个在我们周围不断重复发生的问题，以及该问题的核心解决方案。设计模式可以贯穿在开发乃至重构的过程中，使代码处于优雅且复用的状态以增强软件设计的适应变化能力。这也是设计模式的目的：提高代码可重用性和可靠性，并使代码条理清晰、易于理解、易于维护。
有哪些设计模式可供使用？根据GOF《设计模式》著作中所说，设计模式可以分成三组：创建型(Creational)，结构型(Structural)，行为型(Behavioral)，共23种。
设计模式是复杂的，在引用前要衡量是否有必要给项目引入额外的复杂性。这要求使用者衡量实现某种模式所需的时间与该模式能够带来的效益。
不要在不了解设计模式的情况下使用他们。
使用者需有强大的概括能力，问题抽象出来都错了，谈何使用？
设计原则为什么要提倡设计模式呢？上面提到了设计模式的目的是为了代码复用，增加可维护性。那么怎么才能让开发人员轻松写出可读性和可维护性高的程序呢？
Martin（Uncle Bob）提出了五项原则，这五个原则被称为S.O.L.I.D原则（首字母缩写）：
作为开发者，想必大家都有这样的经验，一个方法参杂越多的交叉业务，它的定义就越不明确，复用性就越低。小至方法，大至模块，承担的职责越多，就等于把这些职责耦合在一起，它被复用的可能性就越小。当一个类具有了多项职责，它被更改的可能性也会增加，当其中一个职责发生变化时，可能会影响其他职责的运作，而每一次由于职责变化发生的改动，也会使得bug产生的风险增加。
所以SRP强调的是：引起类变化的因素永远不要多于一个。这意味着在设计需要的类时，需要考虑使得每个类被设计出来都只有一个目的（或主要目的）。但这并不意味着每个类只能有一个方法，应该是该类中所有的方法都要围绕着该类所描述的主要功能。至于那些有多个职责的类，应该被重新封装成新的类。
OCP - 开闭原则该原则强调的是：一个软件实体（指的类、函数、模块等）应该对扩展开放，对修改关闭。即每次发生变化时，要通过添加新的代码来增强现有类型的行为，而不是修改原有的代码。
为什么要这样呢？我们都有这样的经历，在接手已经在正式上线的项目时，当需要面对新的需求时，我们首要的任务应该是尽量保证系统的设计框架是稳定的。对于一个功能，一般不会因为新功能的原因而去改变之前已经稳定的功能，因为如果你改变它，很可能你的改变会引发系统的崩溃。
OCP提倡的是：你需要一些额外功能，你应该扩展这个类而不是修改它。使用这种方式，现有系统不会看到由于新变化的所带来的影响。同时，你只需要测试新创建的类。与SRP一样，该原理通过尽可能减少对现有代码的更改来降低引入新错误的风险。
符合开闭原则的最好方式是提供一个固有的接口（或抽象类），为系统提供一个相对稳定的抽象层，然后让所有可能发生变化的类实现该接口，让固定的接口与相关对象进行交互，这样如果需要修改系统的行为，只需在抽象层进行新增业务方法，然后增加新的具体类来实现新的业务功能即可。
LSP - 里氏替换原则