Android设计模式系列

http://www.cnblogs.com/qianxudetianxia/category/312863.html

Android设计模式系列(12)--SDK源码之生成器模式（建造者模式）

摘要: 建造者模式把构造和表示分离开，根据客户需求生产一个相应的对象。原本呢，咱们根据Builder接口实现不一样的具体的ConcreteBuilder，就可生产不一样的对象了。可是，下面例子的只有一个Builder，因此也没有接口Builder，也没有其余的ConcreteBuilder。可是我今天要讲的例子太简单，简单到都不以为是建造者模式，可是又有建造者模式的感受。1. 意图将一个复杂对象的构建和它的表示分离，使得一样的建立过程能够建立不一样的表示。2.结构图和代码android中大量的使用对话框组件，它的调用方法就是构建，拼接，表示。Builder经过setTitle(),setMessage(), 阅读全文

posted @  2013-04-19 17:35 谦虚的天下 阅读(6819) |  评论 (4)  编辑

Android设计模式系列(11)--SDK源码之策略模式

摘要: 策略模式其实特别简单（听到这句话，你们是否是内心一会儿放松了？）。好比排序，官方告诉你们我这里有一个排序的接口ISort的sort()方法,而后民间各尽其能，实现这个排序的方法：冒泡，快速，堆等等。这些方法就是“不一样的策略”。而后，某个模块下，须要一个排序方法，可是暂时不能指定具体的sort方法(出于扩展的考虑)，就须要使用ISort接口了。最后，具体什么场景下，传入什么具体的sort方法，实现灵活的排序。这就是策略模式！下面，咱们分析Android中的动画是如何使用策略模式的。1. 意图定义一系列的算法，把它们一个个封装起来，而且使它们可互相替换。策略模式使得算法可独立于使用它的客户而变化。 阅读全文

posted @  2013-04-19 10:56 谦虚的天下 阅读(6809) |  评论 (2)  编辑

Android设计模式系列(10)--SDK源码之原型模式

摘要: CV一族，应该很容易理解原型模式的原理，复制，粘贴完后看具体状况是否修改，其实这就是原型模式。从java的角度看，通常使用原型模式有个明显的特色，就是实现cloneable的clone()方法。原型模式，能快速克隆出一个与已经存在对象相似的另一个咱们想要的新对象。1.意图用原型实例指定建立对象的种类，而且经过拷贝这些原型建立新的对象。热门词汇：克隆 深拷贝 浅拷贝2.结构图和代码它的结构图很是简单，咱们以Intent为例子：Intent的clone方法很是简单： @Override public Object clone() { return new Intent(... 阅读全文

posted @  2012-03-02 13:07 谦虚的天下 阅读(5858) |  评论 (4)  编辑

Android设计模式系列(9)--SDK源码之适配器模式

摘要: 对于android开发者来讲起，适配器模式简直太熟悉不过，有不少应用能够说是每天在直接或者间接的用到适配器模式，好比ListView。ListView用于显示列表数据，可是做为列表数据集合有不少形式，有Array，有Cursor，咱们须要对应的适配器做为桥梁，处理相应的数据（并能造成ListView所须要的视图）。正是由于定义了这些适配器接口和适配器类，才能使咱们的数据简单灵活而又正确的显示到了adapterview的实现类上。适配器模式，Adapter Pattern，勇敢的去适配，大量的资源能够重用。1.意图适配器模式，把一个类的接口变换成客户端所期待的另外一种接口，从而使本来不匹配而没法在 阅读全文

posted @  2012-02-27 23:05 谦虚的天下 阅读(10230) |  评论 (5)  编辑

Android设计模式系列(8)--SDK源码之工厂方法模式

摘要: 工厂方法模式，每每是设计模式初学者入门的模式，的确，有人称之为最为典型最具启发效果的模式。android中用到了太多的工厂类，其中有用工厂方法模式的，固然也有不少工厂并非使用工厂方法模式的，只是工具管理类。今天以ThreadFactory举例说明一下简单工厂模式和工厂方法模式。工厂方法模式，Factory Method,简单的方式，不简单的应用。1.意图定义一个用于建立对象的接口，让子类决定实例化哪一个类。工厂方式模式使一个类的实例化延迟到其子类。热门词汇:虚构造器 延迟 建立对象 子类2.结构图和代码咱们先看看标准的工厂方法结构图：先抽象的产品类，抽象的工厂类，而后用客户端具体的工厂生产相应 阅读全文

posted @  2011-08-20 11:07 谦虚的天下 阅读(9820) |  评论 (5)  编辑

Android设计模式系列(7)--SDK源码之命令模式

摘要: 命令模式，在.net，java平台的事件机制用的很是多，几乎天天都与之打交道。android中对我印象最深的就是多线程多进程的环境，因此必然大量使用到Runbable,Thread,其实用的就是最简单的命令模式。命令模式，Command Pattern，把请求封装为一个对象，多么巧妙的一个说法啊。1.意图将一个请求封装为一个对象，从而使你可用不一样的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操做。热门词汇：动做 事物 请求封装 排队 打包 异步2.结构Command接口提供了Execute方法，客户端经过Invoker调用命令操做来调用Recriver，绕了一大圈，可是却把 阅读全文

posted @  2011-08-13 00:36 谦虚的天下 阅读(6546) |  评论 (2)  编辑

Android设计模式系列(6)--SDK源码之享元模式

摘要: 享元模式,给个人感受就是对象池，缓存单例对象。java中的享元模式最经典的例子就是String类了，还有一个最容易理解的就是word文档字符共享的例子，也是享元模式的经典应用。本文对android中的sql编译类SQLiteCompiledSql说明，展开分析，也是很容易理解的一个例子，其实，android SDK中必然有不少地方须要用到享元模式。享元模式，Flyweight Pattern,说的严重点，一些程序若是不使用享元模式的话，根本不能使用面向对象的方法实现，对象会多的撑爆你的内存："用面向对象思想设计的应用经常会面临对象实例过多的问题"。1.意图运用共享技术有效地 阅读全文

posted @  2011-08-10 22:00 谦虚的天下 阅读(5491) |  评论 (0)  编辑

Android设计模式系列(5)--SDK源码之备忘录模式

摘要: 备忘录模式，在工做代码中，要么不用，要么常常用到。举个例子，程序员喜欢写代码，coding,coding,这个时候它的状态是很high，可是每隔一段时间总要去上一下厕所，状态是放松relax，上完测试归来后又恢复到high的状态，继续coding。这个过程对于身后的老板来讲，它默认赞成你离开去上厕所，他也但愿你回来后恢复high的状态继续工做，可是你在这个过程当中上厕所的这件事，他是不须要了解细节的，并且作为当事人你也不但愿他了解你上厕所的细节吧，你只要回来后恢复激情high着继续工做，老板应该就不会挑你的刺。这就是备忘录模式。本文今天就Canvas的一个save(),restore()操做分析 阅读全文

posted @  2011-08-09 22:21 谦虚的天下 阅读(6172) |  评论 (1)  编辑

Android设计模式系列(4)--SDK源码之模板方法模式

摘要: 模板方法，和单例模式是我认为GOF的23中最简单的两种模式。可是我我的对模板方法的经典思想特别推崇，虽然模板方法在大对数状况下并不被推荐使用，可是这种经过父类调用子类的方法，使用继承来改变算法的一部分，是面向对象的一种基本认识。打比方说父亲有不少理想，就行医救人吧，可是父亲医术不行，只能靠儿子，儿子长大后听从父亲大志，春风拂面，妙手回春，实现了父亲的理想，儿子作的事情早在出生前就定下来了，是父亲以前久定好的模板。认识到模板方法的这种思想，父类可让未知的子类去作它自己可能完成的很差或者根本完成不了的事情，对框架学习大有帮助。本文以View中的draw方法为例，展开分析。模板方法，Templat 阅读全文

posted @  2011-08-09 00:25 谦虚的天下 阅读(6609) |  评论 (4)  编辑

Android设计模式系列(3)--SDK源码之单例模式

摘要: 单例模式，能够说是GOF的23种设计模式中最简单的一个。这个模式相对于其余几个模式比较独立，它只负责控制本身的实例化数量单一(而不是考虑为用户产生什么样的实例)，颇有意思，是一个感受上很干净的模式，本人很喜欢这个模式。android中不少地方都用到了单例模式，本文以输入法管理者InputMethodManager为例，展开分析。单例模式，Singleton Pattern,可以以其特有的优点，替代系统中全局变量，应用很是普遍。1.意图保证一个类仅有一个实例，并提供一个访问它的全局访问点。热门词汇：单例 惟一 私有构造2.结构android中有不少系统级别的全局变量，如时间，输入法，帐户，状态栏 阅读全文

posted @  2011-08-07 21:59 谦虚的天下 阅读(9439) |  评论 (5)  编辑

Android设计模式系列(2)--SDK源码之观察者模式

摘要: 观察者模式，是一种很是常见的设计模式，在不少系统中随处可见，尤为是涉及到数据状态发生变化须要通知的状况下。本文以AbstractCursor为例子，展开分析。观察者模式，Observer Pattern,是一个很实用的模式，本人曾经接触到的各类平台以及曾经参与项目中打印模板解释器中都用到了此模式。1.意图定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，全部依赖于它的对象都获得通知并被自动更新。热门词汇：依赖 发布-订阅 事件 通知 更新 监听2.结构这是一个最简单的观察者模式，目标对象可以添加和删除观察者，当本身某种状态或者行为发生改变时，可经过notify通知注册的观察者进行更 阅读全文

posted @  2011-08-07 00:03 谦虚的天下 阅读(13381) |  评论 (8)  编辑

Android设计模式系列(1)--SDK源码之组合模式

摘要: Android中对组合模式的应用，可谓是泛滥成粥，随处可见，那就是View和ViewGroup类的使用。在android UI设计，几乎全部的widget和布局类都依靠这两个类。组合模式，Composite Pattern，是一个很是巧妙的模式。几乎全部的面向对象系统都应用到了组合模式。1.意图将对象View和ViewGroup组合成树形结构以表示"部分-总体"的层次结构(View能够作为ViewGroup的一部分)。组合模式使得用户对单个对象View和组合对象ViewGroup的使用具备一致性。热点词汇: 部分-总体 容器-内容 树形结构 一致性 叶子 合成 安全性 透明 阅读全文

posted @  2011-07-29 22:53 谦虚的天下 阅读(15757) |  评论 (12)  编辑

Android设计模式系列(0)--开篇

摘要: =======================2011-08-26==================================有时候，最难的是坚持；有时候缺乏的是信念。=======================2011-08-07==================================从接触设计模式到现在大概4年左右的时间，一直都想有朝一日定要精通，坐于床头，侧望左右，设计模式的书买了7,8本了，也看了不少参考和视频，也用到了一些。可是今天我终于停下来，停下来梳理，停下来欣赏，也停下来检讨，总之，我今天停下来了，是为了走的更好，走的更远。若是有幸我可以把这个系列写到23 阅读全文

posted @  2011-07-29 22:51 谦虚的天下 阅读(15705)

 

 

http://blog.csdn.net/banketree/article/details/24985607

项目开发中发现问题、解决问题这个过程当中会出现不少问题，好比重复出现、某个问题的遗留，这些问题的本质就是设计模式。今天记录设计模式的知识点。

内容

在java以及其余的面向对象设计模式中，类与类之间主要有6种关系，他们分别是：依赖、关联、聚合、组合、继承、实现。它们的耦合度依次加强。

依赖关系:
对于两个相对独立的对象，当一个对象负责构造另外一个对象的实例，或者依赖另外一个对象的服务时，这两个对象之间主要体现为依赖关系。
关联关系:
分为单向关联和双向关联。在java中，单向关联表现为：类A当中使用了类B，其中类B是做为类A的成员变量。双向关联表现为：类A当中使用了类B做为成员变量；同时类B中也使用了类A做为成员变量。
聚合关系:
是关联关系的一种，耦合度强于关联，他们的代码表现是相同的，仅仅是在语义上有所区别：关联关系的对象间是相互独立的，而聚合关系的对象之间存在着包容关系，他们之间是“总体-个体”的相互关系。
组合关系：
是一种耦合度更强的关联关系。存在组合关系的类表示“总体-部分”的关联关系，“总体”负责“部分”的生命周期，他们之间是共生共死的；而且“部分”单独存在时没有任何意义。
继承：
表示类与类（或者接口与接口）之间的父子关系。
实现：
表示一个类实现一个或多个接口的方法。

 

设计原则

要点	定义	描述
单一职责原则	不要存在多于一个致使类变动的缘由。通俗的说，即一个类只负责一项职责。	问题由来：类T负责两个不一样的职责：职责P1，职责P2。当因为职责P1需求发生改变而须要修改类T时，有可能会致使本来运行正常的职责P2功能发生故障。 解决方案：遵循单一职责原则。分别创建两个类T一、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
里氏替换原则	定义1：若是对每个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的全部程序 P 在全部的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。 定义2：全部引用基类的地方必须能透明地使用其子类的对象。	问题由来：有一功能P1，由类A完成。现须要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会致使原有功能P1发生故障。 解决方案：当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽可能不要重写父类A的方法，也尽可能不要重载父类A的方法。
依赖倒置原则	高层模块不该该依赖低层模块，两者都应该依赖其抽象；抽象不该该依赖细节；细节应该依赖抽象。	问题由来：类A直接依赖类B，假如要将类A改成依赖类C，则必须经过修改类A的代码来达成。这种场景下，类A通常是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操做；假如修改类A，会给程序带来没必要要的风险。 解决方案：将类A修改成依赖接口I，类B和类C各自实现接口I，类A经过接口I间接与类B或者类C发生联系，则会大大下降修改类A的概率。
接口隔离原则	客户端不该该依赖它不须要的接口；一个类对另外一个类的依赖应该创建在最小的接口上。	问题由来：类A经过接口I依赖类B，类C经过接口I依赖类D，若是接口I对于类A和类B来讲不是最小接口，则类B和类D必须去实现他们不须要的方法。 解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们须要的接口创建依赖关系。也就是采用接口隔离原则。
迪米特法则	一个对象应该对其余对象保持最少的了解。	问题由来：类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另外一个类的影响也越大。 解决方案：尽可能下降类与类之间的耦合。
开闭原则	一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。	问题由来：在软件的生命周期内，由于变化、升级和维护等缘由须要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使咱们不得不对整个功能进行重构，而且须要原有代码通过从新测试。 解决方案：当软件须要变化时，尽可能经过扩展软件实体的行为来实现变化，而不是经过修改已有的代码来实现变化。

 

设计模式

 

要点	定义	描述
单例模式	确保一个类只有一个实例，并且自行实例化并向整个系统提供这个实例。	单例模式注意事项： 只能使用单例类提供的方法获得单例对象，不要使用反射，不然将会实例化一个新对象。不要作断开单例类对象与类中静态引用的危险操做。多线程使用单例使用共享资源时，注意线程安全问题。
工厂方法模式	定义一个用于建立对象的接口，让子类决定实例化哪个类，工厂方法使一个类的实例化延迟到其子类。	在工厂方法模式中，核心的工厂类再也不负责全部的对象的建立，而是将具体建立的工做交给子类去作。这个核心类则摇身一变，成为了一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪个类应当被实例化这种细节。
抽象工厂模式	为建立一组相关或相互依赖的对象提供一个接口，并且无需指定他们的具体类。	在如下状况下，适用于工厂方法模式： (1) 当一个类不知道它所必须建立的对象的类的时候。 (2) 当一个类但愿由它的子类来指定它所建立的对象的时候。 (3) 当类将建立对象的职责委托给多个帮助子类中的某一个，而且你但愿将哪个帮助子类是代理者这一信息局部化的时候。
模版方法模式	定义一个操做中算法的框架，而将一些步骤延迟到子类中，使得子类能够不改变算法的结构便可重定义该算法中的某些特定步骤。	子类能够置换掉父类的可变部分，可是子类却不能够改变模板方法所表明的顶级逻辑。 　　每当定义一个新的子类时，不要按照控制流程的思路去想，而应当按照“责任”的思路去想。换言之，应当考虑哪些操做是必须置换掉的，哪些操做是能够置换掉的，以及哪些操做是不能够置换掉的。使用模板模式可使这些责任变得清晰。
建造者模式	将一个复杂对象的构建与它的表示分离，使得一样的构建过程能够建立不一样的表示。	与抽象工厂的区别：在建造者模式里，有个指导者，由指导者来管理建造者，用户是与指导者联系的，指导者联系建造者最后获得产品。即建造模式能够强制实行一种分步骤进行的建造过程。 　　建造模式是将复杂的内部建立封装在内部，对于外部调用的人来讲，只须要传入建造者和建造工具，对于内部是如何建形成成品的，调用者无需关心。 在Java的应用中JavaMail使用到了该模式。
代理模式	为其余对象提供一种代理以控制对这个对象的访问。	所谓代理，就是一我的或者机构表明另外一我的或者机构采起行动。在一些状况下，一个客户不想或者不可以直接引用一个对象，而代理对象能够在客户端和目标对象之间起到中介的做用。
原型模式	用原型实例指定建立对象的种类，并经过拷贝这些原型建立新的对象。 原型模式要求对象实现一个能够“克隆”自身的接口，这样就能够经过复制一个实例对象自己来建立一个新的实例。这样一来，经过原型实例建立新的对象，就再也不须要关心这个实例自己的类型，只要实现了克隆自身的方法，就能够经过这个方法来获取新的对象，而无须再去经过new来建立。	在Java语言里深度克隆一个对象，经常能够先使对象实现Serializable接口，而后把对象（实际上只是对象的拷贝）写到一个流里（序列化），再从流里读回来（反序列化），即可以重建对象。 原型模式的优势 　　原型模式容许在运行时动态改变具体的实现类型。原型模式能够在运行期间，由客户来注册符合原型接口的实现类型，也能够动态地改变具体的实现类型，看起来接口没有任何变化，但其实运行的已是另一个类实例了。由于克隆一个原型就相似于实例化一个类。 原型模式的缺点 　　原型模式最主要的缺点是每个类都必须配备一个克隆方法。配备克隆方法须要对类的功能进行通盘考虑，这对于全新的类来讲不是很难，而对于已经有的类不必定很容易，特别是当一个类引用不支持序列化的间接对象，或者引用含有循环结构的时候。
中介者模式	用一个中介者对象封装一系列的对象交互，中介者使各对象不须要显示地相互做用，从而使耦合松散，并且能够独立地改变它们之间的交互。 中介者模式的优势 适当地使用中介者模式能够避免同事类之间的过分耦合，使得各同事类之间能够相对独立地使用。 使用中介者模式能够将对象间一对多的关联转变为一对一的关联，使对象间的关系易于理解和维护。 使用中介者模式能够将对象的行为和协做进行抽象，可以比较灵活的处理对象间的相互做用。	适用场景        在面向对象编程中，一个类必然会与其余的类发生依赖关系，彻底独立的类是没有意义的。一个类同时依赖多个类的状况也至关广泛，既然存在这样的状况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可使本来凌乱的对象关系清晰，可是若是滥用，则可能会带来反的效果。通常来讲，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。能够将网状结构变为星状结构，使同事类之间的关系变的清晰一些。        中介者模式是一种比较经常使用的模式，也是一种比较容易被滥用的模式。对于大多数的状况，同事类之间的关系不会复杂到混乱不堪的网状结构，所以，大多数状况下，将对象间的依赖关系封装的同事类内部就能够的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。
命令模式	意图：将一个请求封装为一个对象，从而可用不一样的请求对客户进行参数化；对请求排队或记录日志，以及支持可撤销的操做 动机：将”发出请求的对象”和”接收与执行这些请求的对象”分隔开来。	常见应用： 一、工做队列，线程池，日程安排 二、日志请求(系统恢复) 要点： 一、命令模式将发出请求的对象和执行请求的对象解耦 二、在被解耦的二者之间是经过命令对象进行沟通的。命令对象封装了接收者和一个或一组动做 三、调用者经过调用命令对象的execute()发出请求，这会使得接收者的动做被调用 四、调用者能够接受命令看成参数，甚至在运行时动态的进行 五、命令能够支持撤销，作法是实现一个undo()方法来回到execute()被执行前的状态 六、宏命令是命令的一种简单的延伸，容许调用多个命令。宏方法也能够支持撤销 七、实际操做时，很常见使用"聪明"命令对象，也就是直接实现了请求，而不是将工做委托给接受者(弊端？) 八、命令也能够用来实现日志和事物系统
责任链模式	使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。	一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不容许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的状况。 　　在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求能够最终不被任何接收端对象所接收。 　　纯的责任链模式的实际例子很难找到，通常看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。可是在实际的系统里，纯的责任链很难找到。若是坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。
装饰模式	又名包装(Wrapper)模式，装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。	装饰模式与类继承的区别： 1)    装饰模式是一种动态行为，对已经存在类进行随意组合，而类的继承是一种静态的行为，一个类定义成什么样的，该类的对象便具备什么样的功能，没法动态的改变。 2)    装饰模式扩展的是对象的功能，不须要增长类的数量，而类继承扩展是类的功能，在继承的关系中，若是咱们想增长一个对象的功能，咱们只能经过继承关系，在子类中增长两个方法。 3)    装饰与继承比较图： 4)    装饰模式是在不改变原类文件和使用继承的状况下，动态的扩展一个对象的功能，它是经过建立一个包装对象，也就是装饰来包裹真是的对象。 5.    装饰模式把对客户端的调用委派给被装饰的类，装饰模式的关键在于这种扩展彻底透明的。
策略模式	定义一组算法，将每一个算法都封装起来，而且使他们之间能够互换。 策略模式的好处在于你能够动态的改变对象的行为。	策略模式属于对象行为型模式，主要针对一组算法，将每个算法封装到具备共同接口的独立的类中，从而使得它们能够相互替换。策略模式使得算法能够在不影响 到客户端的状况下发生变化。一般，策略模式适用于当一个应用程序须要实现一种特定的服务或者功能，并且该程序有多种实现方式时使用。
适配器模式	基于现有类所提供的服务，向客户提供接口，以知足客户的指望。 适配器模式的用意是要改变源的接口，以便于目标接口相容。缺省适配的用意稍有不一样，它是为了方便创建一个不平庸的适配器类而提供的一种平庸实现。	适配器模式的优势 　　更好的复用性 　　系统须要使用现有的类，而此类的接口不符合系统的须要。那么经过适配器模式就可让这些功能获得更好的复用。 　　更好的扩展性 　　在实现适配器功能的时候，能够调用本身开发的功能，从而天然地扩展系统的功能。 适配器模式的缺点 　　过多的使用适配器，会让系统很是零乱，不易总体进行把握。好比，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统若是太多出现这种状况，无异于一场灾难。所以若是不是颇有必要，能够不使用适配器，而是直接对系统进行重构。
迭代器模式	提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。	在jdk中,与迭代器相关的接口有两个:Iterator 与 Iterable  Iterator:迭代器，Iterator及其子类一般是迭代器自己的结构与方法；  Iterable:可迭代的，那些想用到迭代器功能的其它类，如AbstractList HashMap等，须要实现该接口。
组合模式	将对象组合成树形结构以表示‘部分-总体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具备一致性。 对象经过实现（继承）统一的接口（抽象类），调用者对单一对象和组合对象的操做具备一致性。	经过实现组合模式，调用者对组合对象的操做与对单一对象的操做具备一致性。调用者不用关心这是组合对象仍是文件，也不用关心组合对象内部的具体结构，就能够调用相关方法，实现功能。
观察者模式	定义对象间一种一对多的依赖关系，使得当每个对象改变状态，则全部依赖于它的对象都会获得通知并自动更新。 观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知全部观察者对象，使它们可以自动更新本身。	在JAVA语言的java.util库里面，提供了一个Observable类以及一个Observer接口，构成JAVA语言对观察者模式的支持。
门面模式	外部与一个子系统的通讯必须经过一个统一的门面对象进行。	门面模式的优势： 　　●　　松散耦合 　　门面模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。 　　●　　简单易用 　　门面模式让子系统更加易用，客户端再也不须要了解子系统内部的实现，也不须要跟众多子系统内部的模块进行交互，只须要跟门面类交互就能够了。 　　●　　更好的划分访问层次 　　经过合理使用Facade，能够帮助咱们更好地划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把须要暴露给外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。
备忘录模式	在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象以外保存这个状态。这样就能够将该对象恢复到原先保存的状态。	备忘录对象是一个用来存储另一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捕捉(Capture)住，并外部化，存储起来，从而能够在未来合适的时候把这个对象还原到存储起来的状态。备忘录模式经常与命令模式和迭代子模式一同使用。
访问者模式	封装某些做用于某种数据结构中各元素的操做，它能够在不改变数据结构的前提下定义做用于这些元素的新的操做。 访问者模式是对象的行为模式。访问者模式的目的是封装一些施加于某种数据结构元素之上的操做。一旦这些操做须要修改的话，接受这个操做的数据结构则能够保持不变。	访问者模式的优势 　　好的扩展性 　　可以在不修改对象结构中的元素的状况下，为对象结构中的元素添加新的功能。 　　好的复用性 　　能够经过访问者来定义整个对象结构通用的功能，从而提升复用程度。 　　分离无关行为 　　能够经过访问者来分离无关的行为，把相关的行为封装在一块儿，构成一个访问者，这样每个访问者的功能都比较单一。 访问者模式的缺点 　　对象结构变化很困难 　　不适用于对象结构中的类常常变化的状况，由于对象结构发生了改变，访问者的接口和访问者的实现都要发生相应的改变，代价过高。 　　破坏封装 　　访问者模式一般须要对象结构开放内部数据给访问者和ObjectStructrue，这破坏了对象的封装性。
状态模式	当一个对象的内在状态改变时容许改变其行为，这个对象看起来像是改变了其类。 状态模式容许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类同样。
解释器模式	给定一种语言，定义他的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。
享元模式	复用咱们内存中已存在的对象，下降系统建立对象实例的性能消耗。 Flyweight在拳击比赛中指最轻量级，即“蝇量级”或“雨量级”，这里选择使用“享元模式”的意译，是由于这样更能反映模式的用意。享元模式是对象的结构模式。享元模式以共享的方式高效地支持大量的细粒度对象。	享元模式采用一个共享来避免大量拥有相同内容对象的开销。这种开销最多见、最直观的就是内存的损耗。享元对象能作到共享的关键是区份内蕴状态(Internal State)和外蕴状态(External State)。
桥梁模式	将抽象和实现解耦，使得二者能够独立地变化。 桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦，使得两者能够独立地变化”。	桥梁模式在Java应用中的一个很是典型的例子就是JDBC驱动器。JDBC为全部的关系型数据库提供一个通用的界面。一个应用系统动态地选择一个合适的驱动器，而后经过驱动器向数据库引擎发出指令。这个过程就是将抽象角色的行为委派给实现角色的过程。

 

项目

写了一个Android的项目体现23中设计模式，项目如图：

 

测试代码：

 

public void onClickSingleMode(View view) { // 单例
        SingleMode.getInstance();
    }

    public void onClickFactoryMethodModel(View view) {// 工厂方法
        IProduct iProduct = new FactoryMethodModel();
        iProduct.productMethod();
        iProduct = new Tree();
        iProduct.productMethod();
    }

    public void onClickAbstractFactoryModel(View view) {// 抽象工厂
        AbstractFactoryModel.test();
    }

    public void onClickTemplateMethodModel(View view) {// 模版方法模式
        TemplateMethodModel.test();
    }

    public void onClickBuilderMode(View view) {// 建造者模式
        BuilderMode.test();
    }

    public void onClickProxyMode(View view) {// 代理模式
        ProxyMode.test();
    }

    public void onClickCloneMode(View view) {// 原型模式
        CloneMode.test();
    }

    public void onClickIntermediaryModel(View view) {// 中介者模式
        IntermediaryModel.test1();
        IntermediaryModel.test2();
    }

    public void onClickCommandMode(View view) {// 命令模式
        CommandMode.test();
    }

    public void onChainOfResponsibilityModel(View view) {// 责任链模式
        ChainOfResponsibilityModel.test();
    }

    public void onClickDecorativeMode(View view) {// 装饰模式
        DecorativeMode.test();
    }

    public void onClickStrategyMode(View view) {// 策略模式
        StrategyMode.test();
    }

    public void onClickIteratorModel(View view) {// 模式
        IteratorModel.test();
    }

    public void onClickCombinationMode(View view) {// 组合模式
        CombinationMode.test();
    }

    public void onClickObserverMode(View view) {// 观察者模式
        ObserverMode.test();
    }

    public void onClickWindowMode(View view) {// 门面模式
        WindowMode.test();
    }

    public void onClickMemoMode(View view) {// 备忘录模式
        MemoMode.test();
    }

    public void onClickVisitorMode(View view) {// 访问者模式
        VisitorMode.test();
    }

    public void onClickStateModel(View view) {// 状态模式
        StateModel.test();
    }

    public void onClickParserMode(View view) {// 解释器模式
        ParserMode.test();
    }

    public void onClickFlyweightMode(View view) {// 享元模式
        FlyweightMode.test();
    }

    public void onClickBridgeMode(View view) {// 桥梁模式
        BridgeMode.test();
    }

 

 

总结

 

若是设计模式在编码设计生涯中用得极少，主要缘由是对设计模式的理解还不够，认识不到问题的存在。
由于不能正确的分析问题、认识问题，固然也不可能很好的解决问题了。

 

 

项目下载