大家在平时的日常工作开发中，可能经常会听到“设计模式” 这个词，那么到底什么是设计模式呢？如果要是按照课本上的方式来讲解，估计十篇博客也无法将它讲解透彻。“设计模式”的理论知识固然重要，但理论也是为了实践所做的基础，不要仅仅被理论就搞昏了头脑。
“设计模式”顾名思义，就是设计软件体系时所使用的一系列模式，而这些模式是不会变化的或者说只会在很小的程度上变化，但每种模式的整体结构是基本不变的。所以可以说，每一种设计模式都对应着一种问题的解决方案。而要在项目中使用这些方案，就要看哪一种设计模式更加适合自己的方案了。抽象的讲，设计模式是可以解决一类软件问题并能够重复使用的软件设计方案。
软件开发设计模式速谈：一、概论
“设计模式”是可复用的，也就是说很多结构或功能十分相似的工程项目均可以使用同一种“设计模式”来处理。在选择使用的"设计模式"时要关注程序整体的思路而不是过分的细节。因为“设计模式”是将项目的解决方案整体抽象出来，在类和对象的层次进行描述的。
“设计模式”的核心思想是“通过增加抽象层，把变化的部分从那些不变的部分中分离出来”。在接下来的所有“设计模式速谈”文章中，针对每一种“设计模式”，我们会结合相应的例子来帮助大家理解“设计模式”在实际的工程中的应用，而不是单纯的理论概念。
所有的设计模式都是建立在以下五种原则之上的：
1、“开-闭”原则（Open Closed Principle，OCP）
软件设计应该对扩展是开放的，对修改时封闭的。OCP 原则可以理解为我们可以对软件系统进行功能上的扩展，但在进行扩展时不应该修改原有的系统代码。即在扩展时应该逐步迭代式开发，比如 jQuery.extend()。
2、单一职责原则（Single Responsibility Principle, SRP）
就一个类而言，应该有且只有一个引起其变化的原因，即只有一个职责。比如 Modem 类有两个方法，一个负责管理连接，一个负责通讯，则这个类便违背了 SRP 原则。Modem 类应该只用来负责通讯。所谓的“职责”可以理解为一个类所包含的功能范畴，这些功能应该全部属于同一个范畴之内。比如 Modem 类负责通讯，可以有调整通讯协议，调整通讯方式等方法，而管理连接则不应该属于通讯的范畴，即不应该属于 Modem 类。
3、里氏替换原则（Liskov Substitution Principle, LSP)
继承必须确保超类（父类）所拥有性质在子类中仍然成立。LSP 原则是继承的“基石”，类之间的父子关系只有满足 LSP 原则时，才能称谓是继承关系。而确保 LSP 原则的方法是：只有当子类能够“替换”掉其父类，并且系统功能不受影响时，父类才能够正在的被复用，子类也能够在父类的基础上增加新的功能。例如：父类-鸟，子类-企鹅，则这个关系违背了 LSP 原则，因为父类的鸟有“飞”这个方法，但是企鹅并不会飞。
4、依赖倒置原则（Dependence Inversion Principle, DIP）
高层模块不应该依赖低层模块，二者都应该依赖于抽象。即父类应该是绝对抽象的，而不能是具体的，这样其子类才可以处理所有的情况。例如：父类-人，有一个“吃水果”的方法，而这个方法的参数是“苹果”，这个关系便违背了 DIP 原则，事实上这个“吃水果”的方法应该以更加抽象的“水果”为参数。
5、接口隔离原则（Interface Segregation Principle, ISP）
多个和客户相关的接口要好于一个通用的接口。这个原则很好理解，永远不要尝试去开发一个“通用”的接口，根据不同的使用者将功能独立出来是更好的选择。即一个类应该只对应一个使用者，按照功能或者属性尽量的去划分。
这里再多说一句，设计模式根据应用的角度被分为 “创建型”，“结构型”，“行为型” 三种类型的设计模式。“创建型” 可以理解为用来创建对象的模式，这些模式抽象了实例化的过程。“结构型” 讨论的是类和对象间的结构，这些模式实现了不同的类继承关系。“行为型” 着力解决的是类实体之间的通讯关系，即某一具体的控制流程。
之后的文章，我们将会对常用的设计模式进行逐一的讲解。
閱讀更多 螞蟻大喇叭 的文章
