故不积跬步无以至千里

桥接模式也称为桥梁模式，是结构型设计模式之一；将抽象部分与实现部分分离，使它们都可以独立地进行变化；如果一个系统需要在构建的抽象化角色和具体化角色之间增加更多的灵活性，避免在两个层次之间建立静态的继承联系，可以通过桥接模式使它们在抽象层建立一个关联关系；对于那些不希望使用继承或因为多层次继承导致系统类的个数急剧增加的系统，也可以考虑使用桥接模式；一个类存在两个独立变化的维度，且这两个维度都需要进行扩展；

外观模式也称门面模式，在开发过程中的运用频率非常高；要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行；门面模式提供一个高层次的接口，使得子系统更易于使用；为一个复杂子系统提供一个简单接口；外观模式可以提供一个简单统一的接口，对外隐藏子系统的具体实现、隔离变化；需要构建一个层次结构的子系统时，使用门面模式定义子系统中每层的入口点；如果子系统之间是相互依赖的，你可以让他们仅通过门面接口进行通信，从而简化它们之间的依赖关系；UML类图：系统对外的统一接口，系统内部系统地工作；子系统接口；

享元模式是对象池的一种实现，用来尽可能减少内存使用量，适合用于可能存在大量重复对象的场景，来缓存可共享的对象；使用共享对象可有效地支持大量的细粒度的对象；系统中存在大量的相似对象；细粒度的对象都具备较接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份；需要缓冲池的场景；UML类图：享元对象抽象基类或者接口；具体的享元对象；享元工厂，负责管理享元对象池和创建享元对象；大幅度地降低内存中对象的数量，降低程序内存占用；

装饰模式也称为包装模式，结构型设计模式之一；动态地给一个对象添加一些额外的职责。就增加功能来说，装饰模式生成子类更为灵活；需要透明且动态地扩展类的功能时；UML类图：抽象组件，可以是一个接口或抽象类，充当的就是被装饰的原始对象；组件具体实现类了；该类是Component类的基本实现，也是我们装饰的具体对象；抽象装饰者，为了装饰我们的组件对象，内部持有一个指向组件对象的引用，该类为抽象类，需要根据不同的装饰逻辑实现不同的具体子类；装饰者具体实现类，对抽象装饰者的具体实现；

适配器模式在Android开发中使用率很高，如ListView、；适配器模式把一个类的接口变换成客户端所期待的另一个接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作；系统需要使用现成的类，而此类的接口不符合系统的需要，即接口不兼容；想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作；需要一个统一的输出接口，而输入端的类型不可预知；类适配器模式和对象适配器模式；优点：更好的复用性。

组合模式也称为部分整体模式，结构型设计模式之一；将对象组合成树形结构以表示“部分-整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性；表示对象的部分-整体的层次结构时；从一个整体中能够独立出部分模块或功能的场景；组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让高层模块忽略了层次的差异，方便对整个层次结构进行控制；在新增构件时不好对枝干中的构件类型进行限制，不能依赖类型系统来施加约束，因为大多情况下，他们都来自于相同的抽象层；ღ( ´･ᴗ･` )

代理模式也称为委托模式，是一种结构型设计模式；为其他对象提供一种代理以控制对这个对象的访问；当无法或不想直接访问某个对象或访问某个对象存在困难时，可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口；UML类图：抽象主题类，该类的主要职责是申明真实主题与代理的共同接口方法，该类即可以是一个抽象类也可以是一个接口；

中介者模式也称为调解者或调停者模式；中介者模式包装了一系列对象相互作用的方式，使得这些对象不必相互明显作用，从而使它们可以松散耦合；当某些对象之间的作用发生改变时，不会立即影响其他的一些对象之间的作用。保证这些作用可以彼此独立变化。中介者模式将多对多的相互作用转化为一对多的相互作用。中介者模式将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理；使用场景：当对象之间的交互操作很多且每个对象的行为操作都依赖彼此时，为防止在修改一个对象的行为时，同时涉及修改很多其他对象的行为。

访问者模式是一种将数据操作与数据结构分离的设计模式；封装一些作用于某种数据结构中的各元素的操作，它可以在不改变这个数据结构的前提下定义作用于这些元素的新的操作；对象结构比较稳定，但经常需要在此对象结构上定义新的操作；需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免这些操作“污染”这些对象的类，也不希望在增加新操作时修改这些类；

定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤；多个子类有公有的方法，并且逻辑基本相同时；重要、复杂的算法，可以把核心算法设计为模板方法，周边的相关细节功能则由各个子类实现；重构时，模板方法模式是一个经常使用的模式，把相同的代码抽取到父类中，然后通过钩子函数约束行为；UML类图：抽象类，定义了一套算法框架；具体实现类；封装不变部分，扩展可变部分；提供共用部分代码，便于维护；

迭代器模式又称为游标模式，是行为型设计模式；提供一种方法顺序访问一个容器对象中的各个元素，而又不需要暴露该对象的内部表示；遍历一个容器对象时；UML类图：迭代器接口，负责定义、访问和遍历元素的接口；具体迭代器类，实现迭代器接口，并记录遍历的当前位置；容器接口，负责提供创建具体迭代器角色；具体容器类；迭代器模式发展至今，几乎每一种高级语言都已经内置实现，极少需要自己去实现迭代器；支持以不同的方式去遍历一个容器对象，也可以有多个遍历，弱化了容器类与遍历算法之间的关系；类文件的增加；ღ( ´･ᴗ･` )

备忘录模式是一种行为模式，该模式用于保存对象当前状态，并且在之后可以再次恢复到此状态；在不破坏封闭的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样，以后就可以将该对象恢复到原先保存的状态；需要保存一个对象在某一个时刻的状态或部分状态；如果用一个接口来让其他对象得到这些状态，将会暴露对象的实现细节并破坏对象的封装性，一个对象不希望外界直接访问其内部状态，通过中间对象可以间接访问其内部状态；UML类图：备忘录角色，用于存储Originator内部状态，并且可以防止Originator。

观察者常用于订阅-发布系统，能够将观察者和被观察者进行解耦，降低两者之间的依赖；定义对象间一种一对多的依赖关系，使得每当一个对象改变状态时，则所有依赖于它的对象都会得到通知并被自动更新。关联行为场景，需要注意的是，关联行为是可拆分的，而不是组合关系；事件多级触发场景；跨系统的消息交换场景，如消息队列、事件总线的处理机制。UML类图：抽象主题，被观察者的角色，抽象主题角色把所有观察者对象的引用保存到一个集合中，每个主题都可以有任意数量的观察者，抽象主题提供一个接口，可以增加和删除观察对象；

命令模式是行为型设计模式之一；将一个请求封装成一个对象，从而让用户使用不同的请求把客户端参数化；对请求排队或者记录日志，以及支持可撤销的操作；需要抽象出待执行的动作，然后以参数的形式提供出来，类似于过程设计中的回调机制，而命令模式正是回调机制的一个面对对象的替代品；在不同的时刻指定、排列和执行请求。一个命令对象可以有与初始请求无关的生存期；需要支持取消操作；支持修改日志功能，这样当系统崩溃时，这些修改可以被重做一遍；需要支持事务操作；UML类图：客户端角色；请求者角色；

表示拥有的关系，如一个类知道另一个类的属性和方法；整体与部分的关系，但部分不能离开整体而单独存在；使用的关系，即一个类的实现需要另一个类的协助；整体与部分的关系，部分可以离开整体存在；局部变量，方法的参数，对静态方法的调用；带普通箭头的实线，指向被拥有者；带箭头的虚线，箭头指向被使用者；带三角箭头的实线，箭头指向父类；带三角箭头的虚线，箭头指向接口；继承关系，一般与特殊的关系；实现关系，类与接口的关系；的实线，菱形指向整体；的实线，菱形指向整体；

解释器模式是一种使用较少的行为型模式；提供了一种解释语言的语法或表达式的方式，通过该接口解释一个特定的上下文。给定一个语言，定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。如果某个简单的语言需要解释执行而且可以将该语言中的语句表示为一个抽象语法树时，可以考虑使用解释器模式。如一个简单的含有加减运算的数学表达式：p+q+m-n,像这样的表达式其构成无非就两种，一种是以pqmn这类的具体参数表示的符号，其无法再被推导，我们称为终结符号；

责任链模式是行为型设计模式；使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定；在请求处理者不明确的情况下向多个对象中的一个提交一个请求；需要动态指定一组对象处理请求；UML类图：抽象处理者角色；保持对下一个节点处理者对象的引用；处理请求；获取处理者对象的处理级别；每个处理者对象的具体处理方式；抽象请求者角色；处理对象；

状态模式中的行为是由状态来决定的，不同的状态下有不同的行为。状态模式和策略模式的结构几乎完全一样，但他们的目的、本质却完全不一样。状态模式的行为是平行的、不可替换的，而策略模式的行为是彼此独立、可互相替换的。状态模式把对象的行为包装咋不同的状态对象里，每一个状态对象都有一个共同的抽象状态基类。状态模式的意图是让一个对象在其内部状态改变的时候，其行为也随之改变。当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。

定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。针对同一类型问题的多种处理方式，仅仅是具体行为有差别时；需要安全地封装多种同一类型的操作时；出现同一抽象类有多个子类，而又需要使用if-else或者switch-case来选择具体子类时；策略模式主要用来分离算法，在相同的行为抽象下有不同的具体实现策略。这个模式很好地演示了开闭原则，也就是定义抽象，注入不同的实现，而从达到很好的可扩展性。结构清晰明了、使用简单直观；

前面我们介绍了工厂方式模式Android设计模式详解之工厂方法模式，抽象工厂模式类似，同样是创建型设计模式；为创建一组相关或者是相互依赖的对象提供一个接口，而不需要指定它们的具体类。一个对象族有相同的约束时可以使用抽象工厂模式；使用抽象工厂从具体的产品实现中解耦，基于接口与实现的分离，使抽象工厂方法模式在切换产品类时更加灵活；类文件爆炸性增加；不太容易扩展新的产品类；ღ( ´･ᴗ･` )

工厂方式模式是创建型设计模式；定义一个用于创建对象的接口，让子类决定实例化哪个类。在任何需要生成复杂对象的地方，都可以使用工厂方法模式。复杂对象适合使用工厂模式，用new就可以完成创建的对象无需使用工厂模式。UML类图：抽象产品；具体产品；抽象工厂；具体工厂；对象的创建统一交给工厂去生成，有良好的封装性，同时也做到了解耦，也满足最少知识原则；每次添加新的产品都需要新增产品类和对应的工厂类，会导致类结构复杂化，因此需要结合实际情况去评估是否使用工厂模式。ღ( ´･ᴗ･` )

原型模式是一个创建型设计模式。用原型实例指定创建对象的种类，并通过复制这些原型创建新的对象。类初始化需要消耗非常多的资源，这个资源包括数据、硬件资源，通过原型复制避免这些消耗；通过new产生一个对象需要非常繁琐的数据准备或访问权限；一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式复制多个对象供调用者使用，即保护性拷贝。

Builder模式是一种创建型设计模式。将一个复杂对象的创建与它的表示分离，使得同样的构造过程可以创建不同的表示。相同的方法，不同的执行顺序，产生不同的事件结果时；多个部件或零件，都可以装配到一个对象中，但是产生的运行结果又不相同时；初始化一个对象特别复杂，如参数较多，且很多参数都具有默认值时；UML类图：产品类；抽象Builder类，规范产品的组建，一般由子类实现具体的组建过程；具体的Builder类；统一组装过程；良好的封装性，使用建造者模式可以使客户端不必知道产品内部组成的细节；

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。确保某个类有且仅有一个对象的场景，避免产生多个对象消耗过多的资源。比如要访问IO和数据库资源，应该考虑使用单例模式。单例模式是运用频率很高的模式；内存中只有一个实例，减少了内存开销；可以避免对资源的多重占用；可以全局共享资源，方便数据访问；一般没有接口，扩展性较差，扩展只能通过修改代码来实现；如果持有Context，容易引发内存泄漏，注意传递给单例对象的Context应为；ღ( ´･ᴗ･` )

我们知道有23种设计模式，通过使用这些设计模式，我们可以更好的解决一些开发中碰到的难题，当然这23种设计模式的设计前提也是建立在六大原则基础上之上的。我们编写的代码符合这六大原则，有助有提高我们代码的质量，体现出可扩展、可维护、可读性好、低耦合、高内聚。