设计模式

一、设计模式的分类：

设计模式可以分为三大类：

1 创建型模式，一共有5种：工厂方法模式，抽象工厂模式，单例模式，建造者模式，原型模式。

2 结构型模式， 一共有7种：适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式。

3 行为型模式， 一共有11种：策略模式，模板方法模式，观察者模式，迭代器模式，责任链模式，命令模式，备忘录模式，状态模式，访问者模式，中介者模式，解释器模式

序号	模式 & 描述	包括
1	创建型模式 这些设计模式提供了一种在创建对象的同时隐藏创建逻辑的方式，而不是使用新的运算符直接实例化对象。这使得程序在判断针对某个给定实例需要创建哪些对象时更加灵活。避免用户直接使用new运算符创建对象。	工厂模式（Factory Pattern） 抽象工厂模式（Abstract Factory Pattern） 单例模式（Singleton Pattern） 建造者模式（Builder Pattern） 原型模式（Prototype Pattern）
2	结构型模式 这些设计模式关注类和对象的组合。继承的概念被用来组合接口和定义组合对象获得新功能的方式。	适配器模式（Adapter Pattern） 桥接模式（Bridge Pattern） 过滤器模式（Filter、Criteria Pattern） 组合模式（Composite Pattern） 装饰器模式（Decorator Pattern） 外观模式（Facade Pattern） 享元模式（Flyweight Pattern） 代理模式（Proxy Pattern）
3	行为型模式 这些设计模式特别关注对象之间的通信。	责任链模式（Chain of Responsibility Pattern） 命令模式（Command Pattern） 解释器模式（Interpreter Pattern） 迭代器模式（Iterator Pattern） 中介者模式（Mediator Pattern） 备忘录模式（Memento Pattern） 观察者模式（Observer Pattern） 状态模式（State Pattern） 空对象模式（Null Object Pattern） 策略模式（Strategy Pattern） 模板模式（Template Pattern） 访问者模式（Visitor Pattern）
4	J2EE 模式 这些设计模式特别关注表示层。这些模式是由 Sun Java Center 鉴定的。	MVC 模式（MVC Pattern） 业务代表模式（Business Delegate Pattern） 组合实体模式（Composite Entity Pattern） 数据访问对象模式（Data Access Object Pattern） 前端控制器模式（Front Controller Pattern） 拦截过滤器模式（Intercepting Filter Pattern） 服务定位器模式（Service Locator Pattern） 传输对象模式（Transfer Object Pattern）

以上是23种设计模式，实际上，这23种设计模式都来自于 6大设计原则

二、6大设计原则

1，开闭原则

   定义：一个软件的实体如类，模块应该对拓展开放，对修改关闭

   该设计原则是6大设计原则的大哥大，我们所要设计的某个类的时候就应该想明白该类负责哪些职责，不应到了后期修改代码，应当尽可能的去拓展代码。换成安卓开发中，我们应当尽可能的使用接口和抽象类。

2，里氏替换原则

   定义：任何基类可以出现的地方，子类一定可以出现，即子类一定要可以替代父类

   对于该设计原则，简单的说就是子类不可更改父类的功能和方法，如果更改，可能会导致不可预知的错误，给代码带来难以维护的后果。假设一组继承关系中，父类需要修改，必须考虑到其所有的子类。

3，依赖倒置原则

   定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象

   依赖导致设计原则是开闭原则的基础，简单的说是面向接口编程，应对依赖于抽象，而不依赖于具体。在Java中，细节即实现类是多变的，抽象的东西相对于稳定的多，以抽象为基础搭建起来的架构比以细节搭建起来的架构稳定的多，该设计原则的核心是面向接口编程。

4，接口隔离原则

   定义：一个实现类不应该依赖于它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口之上

   简单的说就是使用多个隔离的接口比使用单独一个接口要好，实质上是降低耦合的意思，一个类不应去实现他们不需要的方法，应当接口拆分开来使用

5，迪米特原则

   定于：一个对象应当对其他对象保持最少的了解

   这个很容易理解，设计功能模块，应当相对独立，尽量少的与其他对象产生耦合，如果不按这么去做，可能会导致系统十分臃肿，维护一个功能模块的方法导致另一个功能模块也要跟着维护，增加工作量。

6，单一职责原则

   定于：不要存在多于一个导致类变更的原因

   通俗的去讲，即一个类只负责一个功能，本质上讲和迪米特法则有些相似，是为了减少需求改变时产生的影响，如不遵守，会导致维护成本上升，代码可读性下降