什么是模式？
模式是在某种情景下对某些问题的解决方案。
是不是一定用上模式的代码才是好代码？
不是，用简单合适的方法解决问题。不要遇到什么问题都用必杀技，必杀技也需要酝酿的时间，如果可以一拳把对方秒杀的话，压根没必要用必杀技。
那什么时候才需要用设计模式?
设计模式不是刻意去运用的，而是遇到某个情景，触发到你的印象种的某些设计模式的条件，那么意味着用它们可以减少日后的维护成本，总的来时使用设计模式是一个很自然的过程。
《Head First 设计模式》提到的设计模式
| 模式 | 描述 |
| 装饰者 | 包装一个类，提供新的行为。 |
| 状态 | 封装了基于状态的行为，并使用委托在行为之间切换。 |
| 迭代器 | 在对象的集合之中游走，而不暴露集合的实现。 |
| 外观 | 简化一群类的接口。 |
| 策略 | 封装可以互换的行为，并使用委托来决定要使用哪一个。 |
| 代理 | 包装对象，以控制对此对象的访问。 |
| 工厂方法 | 由子类决定要创建的具体类是哪一个。 |
| 适配器 | 封装对象，提供不同接口。 |
| 观察者 | 让对象能够在状态改变时被通知。 |
| 模板方法 | 由子类决定如何实现一个算法中的步骤。 |
| 组合 | 客户用一致的方式处理对象集合和单个对象。 |
| 单件 | 确保有且只有一个对象对象被创建。 |
| 抽象工厂 | 允许创建对象的家族，而无需制定他的具体类。 |
| 命令 | 封装请求成为对象。 |
Ps:下文会列举简单的例子解析。
OO基础
抽象
封装
多态
继承
OO原则
封装变化
多用组合，少用继承
针对接口编程，不针对实现编程
为交换对象之间的松耦合设计而努力
类应该对扩展开放，对修改关闭
依赖抽象，不依赖具体类
只和朋友交谈
别找我，我会找你
类应该只有一个改变的理由
个人观点: 整个设计模式的核心是为了以后更好的维护，所以设计原则 为 高内聚，低耦合 ，详细的原则，上文OO原则提到。
设计模式实例解释（非代码）：
装饰者：
使用条件：给一个类提供新的行为。
平民+手枪 = 民警
民警+冲锋枪 = 特种兵
...
状态：
使用条件：行为类，存在多种状态而导致有多种行为，每次维护需要修改里面的代码（if...），所有把它的每个状态定义为一个类方便日后拓展。
行为：学习 + 说话 + ...
状态：喜怒哀乐...
状态类：
喜：好好学习 + 滔滔不绝...
怒：不想学习 + 说话很愤青...
哀：不想学习 + 沉默寡言...
乐：越学越兴奋 + 主动找人分享...
迭代器：
使用条件：给外界提供一个方法，调用它便可获取不同类的数据，外界不需要接触其底层。
A (Boss)
B (管理层)
C (底层：C1生产部，C2运输部、C3市场部...)
A需要知道底层员工的工作时间
C 的每一个类实现一个相同的方法（接口B），A 通过询问 B ， 便实现对C的访问，
外观：
使用条件：定义一个高层接口，让子系统更容易使用。
包青天，手下有很多（公孙策，展昭，张龙赵虎...），办案的时候，为了方便，叫阿四（接口），而不用具体到某个人办案即可。
策略：
使用条件：封装不同的算法，使他们之间可以互换。实现：通过定义算法接口，再有不同的算法实现。
小明 要 吃饭（算法）
吃饭 = {中餐、西餐、寿司...}
代理：
使用条件：不希望外界直接访问类，需要一个辅助类作为媒介，选择性地提供信息。
邀请明星做嘉宾
宝洁公司（邀请方）—— 经纪人 —— 大明星
工厂方法：
使用条件：产品跟生产过程分开。
汉堡={麦当劳+KFC}
抽象工厂方法：
使用条件：把对象内部数据也抽象了。
汉堡 from {A工厂 + B 工厂}
汉堡 = 生菜(抽象){进口 + 国产 ...}
适配器:
使用条件：已有接口，但需要转换才能产生出目标接口。
苹果充电器->适配器->插座
观察者：
使用条件：不需要主动探测数据源是否有更新，当在数据源注册之后，数据若有更行，数据源会主动发通知过来。
老师报置作业——>学委——>学生（观察者）
模板方法：
使用条件：使用泛化的思想，把不同类中的类似方法抽象出来。
常跟迭代器组合一起运用。
各种排序算法
组合：
使用条件：让我们以树形方式创建对象的结构，以一致的方式，处理对象以及对象的组合。
列出A公司所有代理产品名称
A公司={洗发水 + 沐浴露 + B子公司}
B公司= {香水 + 洗面奶}
单件：
使用条件：确保只有只有一个对象产生。
洗手间只有一个，由所有人共享。
命令：
使用条件：把方法封装起来，通过使用一个类把相关方法封装。
一键XX，如一键刷机。
经典书籍：
《Design Patterns》