http://www.cnblogs.com/qianxudetianxia/category/312863.html
摘要: 建造者模式把构造和表示分离开，根据客户需求生产一个相应的对象。本来呢，我们根据Builder接口实现不同的具体的ConcreteBuilder，就可生产不同的对象了。但是，下面例子的只有一个Builder，所以也没有接口Builder，也没有其他的ConcreteBuilder。但是我今天要讲的例子太简单，简单到都不觉得是建造者模式，但是又有建造者模式的感觉。1. 意图将一个复杂对象的构建和它的表示分离，使得同样的创建过程可以创建不同的表示。2.结构图和代码android中大量的使用对话框组件，它的调用方法就是构建，拼接，表示。Builder通过setTitle(),setMessage(),阅读全文
摘要: 策略模式其实特别简单（听到这句话，大家是不是心里一下子放松了？）。比如排序，官方告诉大家我这里有一个排序的接口ISort的sort()方法,然后民间各尽其能，实现这个排序的方法：冒泡，快速，堆等等。这些方法就是“不同的策略”。然后，某个模块下，需要一个排序方法，但是暂时不能指定具体的sort方法(出于扩展的考虑)，就需要使用ISort接口了。最后，具体什么场景下，传入什么具体的sort方法，实现灵活的排序。这就是策略模式！下面，我们分析Android中的动画是如何使用策略模式的。1. 意图定义一系列的算法，把它们一个个封装起来，并且使它们可互相替换。策略模式使得算法可独立于使用它的客户而变化。阅读全文
摘要: CV一族，应该很容易理解原型模式的原理，复制，粘贴完后看具体情况是否修改，其实这就是原型模式。从java的角度看，一般使用原型模式有个明显的特点，就是实现cloneable的clone()方法。原型模式，能快速克隆出一个与已经存在对象类似的另外一个我们想要的新对象。1.意图用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。热门词汇：克隆 深拷贝 浅拷贝2.结构图和代码它的结构图非常简单，我们以Intent为例子：Intent的clone方法非常简单： @Override public Object clone() { return new Intent(...阅读全文
摘要: 对于android开发者来说起，适配器模式简直太熟悉不过，有很多应用可以说是天天在直接或者间接的用到适配器模式，比如ListView。ListView用于显示列表数据，但是作为列表数据集合有很多形式，有Array，有Cursor，我们需要对应的适配器作为桥梁，处理相应的数据（并能形成ListView所需要的视图）。正是因为定义了这些适配器接口和适配器类，才能使我们的数据简单灵活而又正确的显示到了adapterview的实现类上。适配器模式，Adapter Pattern，勇敢的去适配，大量的资源可以重用。1.意图适配器模式，把一个类的接口变换成客户端所期待的另一种接口，从而使原本不匹配而无法在阅读全文
摘要: 工厂方法模式，往往是设计模式初学者入门的模式，的确，有人称之为最为典型最具启发效果的模式。android中用到了太多的工厂类，其中有用工厂方法模式的，当然也有很多工厂并不是使用工厂方法模式的，只是工具管理类。今天以ThreadFactory举例说明一下简单工厂模式和工厂方法模式。工厂方法模式，Factory Method,简单的方式，不简单的应用。1.意图定义一个用于创建对象的接口，让子类决定实例化哪个类。工厂方式模式使一个类的实例化延迟到其子类。热门词汇:虚构造器 延迟 创建对象 子类2.结构图和代码我们先看看标准的工厂方法结构图：先抽象的产品类，抽象的工厂类，然后用客户端具体的工厂生产相应阅读全文
摘要: 命令模式，在.net，java平台的事件机制用的非常多，几乎每天都与之打交道。android中对我印象最深的就是多线程多进程的环境，所以必然大量使用到Runbable,Thread,其实用的就是最简单的命令模式。命令模式，Command Pattern，把请求封装为一个对象，多么巧妙的一个说法啊。1.意图将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化，对请求排队或记录请求日志，以及支持可撤销的操作。热门词汇：动作 事物 请求封装 排队 打包 异步2.结构Command接口提供了Execute方法，客户端通过Invoker调用命令操作来调用Recriver，绕了一大圈，但是却把阅读全文
摘要: 享元模式,给我的感觉就是对象池，缓存单例对象。java中的享元模式最经典的例子就是String类了，还有一个最容易理解的就是word文档字符共享的例子，也是享元模式的经典应用。本文对android中的sql编译类SQLiteCompiledSql说明，展开分析，也是很容易理解的一个例子，其实，android SDK中必然有很多地方需要用到享元模式。享元模式，Flyweight Pattern,说的严重点，一些程序如果不使用享元模式的话，根本不能使用面向对象的方法实现，对象会多的撑爆你的内存："用面向对象思想设计的应用常常会面临对象实例过多的问题"。1.意图运用共享技术有效地阅读全文
摘要: 备忘录模式，在工作代码中，要么不用，要么经常用到。举个例子，程序员喜欢写代码，coding,coding,这个时候它的状态是很high，但是每隔一段时间总要去上一下厕所，状态是放松relax，上完测试归来后又恢复到high的状态，继续coding。这个过程对于身后的老板来说，它默认同意你离开去上厕所，他也希望你回来后恢复high的状态继续工作，但是你在这个过程中上厕所的这件事，他是不需要了解细节的，而且做为当事人你也不希望他了解你上厕所的细节吧，你只要回来后恢复激情high着继续工作，老板应该就不会挑你的刺。这就是备忘录模式。本文今天就Canvas的一个save(),restore()操作分析阅读全文
摘要: 模板方法，和单例模式是我认为GOF的23中最简单的两种模式。但是我个人对模板方法的经典思想特别推崇，虽然模板方法在大对数情况下并不被推荐使用，但是这种通过父类调用子类的方法，使用继承来改变算法的一部分，是面向对象的一种基本认识。打比方说父亲有很多理想，就行医救人吧，但是父亲医术不行，只能靠儿子，儿子长大后遵从父亲大志，春风拂面，妙手回春，实现了父亲的理想，儿子做的事情早在出生前就定下来了，是父亲之前久定好的模板。认识到模板方法的这种思想，父类可以让未知的子类去做它本身可能完成的不好或者根本完成不了的事情，对框架学习大有帮助。本文以View中的draw方法为例，展开分析。模板方法，Templat阅读全文
摘要: 单例模式，可以说是GOF的23种设计模式中最简单的一个。这个模式相对于其他几个模式比较独立，它只负责控制自己的实例化数量单一(而不是考虑为用户产生什么样的实例)，很有意思，是一个感觉上很干净的模式，本人很喜欢这个模式。android中很多地方都用到了单例模式，本文以输入法管理者InputMethodManager为例，展开分析。单例模式，Singleton Pattern,能够以其特有的优势，替代系统中全局变量，应用非常广泛。1.意图保证一个类仅有一个实例，并提供一个访问它的全局访问点。热门词汇：单例 唯一 私有构造2.结构android中有很多系统级别的全局变量，如时间，输入法，账户，状态栏阅读全文
摘要: 观察者模式，是一种非常常见的设计模式，在很多系统中随处可见，尤其是涉及到数据状态发生变化需要通知的情况下。本文以AbstractCursor为例子，展开分析。观察者模式，Observer Pattern,是一个很实用的模式，本人曾经接触到的各种平台以及曾经参与项目中打印模板解释器中都用到了此模式。1.意图定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。热门词汇：依赖 发布-订阅 事件 通知 更新 监听2.结构这是一个最简单的观察者模式，目标对象能够添加和删除观察者，当自己某种状态或者行为发生改变时，可通过notify通知注册的观察者进行更阅读全文
摘要: Android中对组合模式的应用，可谓是泛滥成粥，随处可见，那就是View和ViewGroup类的使用。在android UI设计，几乎所有的widget和布局类都依靠这两个类。组合模式，Composite Pattern，是一个非常巧妙的模式。几乎所有的面向对象系统都应用到了组合模式。1.意图将对象View和ViewGroup组合成树形结构以表示"部分-整体"的层次结构(View可以做为ViewGroup的一部分)。组合模式使得用户对单个对象View和组合对象ViewGroup的使用具有一致性。热点词汇: 部分-整体 容器-内容 树形结构 一致性 叶子 合成 安全性 透明阅读全文
摘要: =======================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功能发生故障。
解决方案：遵循单一职责原则。分别建立两个类T1、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接口，然后把对象（实际上只是对象的拷贝）写到一个流里（序列化），再从流里读回来（反序列化），便可以重建对象。
原型模式的优点 原型模式的缺点 |
| 中介者模式 | 用一个中介者对象封装一系列的对象交互，中介者使各对象不需要显示地相互作用，从而使耦合松散，而且可以独立地改变它们之间的交互。
中介者模式的优点 |
适用场景 在面向对象编程中，一个类必然会与其他的类发生依赖关系，完全独立的类是没有意义的。一个类同时依赖多个类的情况也相当普遍，既然存在这样的情况，说明，一对多的依赖关系有它的合理性，适当的使用中介者模式可以使原本凌乱的对象关系清晰，但是如果滥用，则可能会带来反的效果。一般来说，只有对于那种同事类之间是网状结构的关系，才会考虑使用中介者模式。可以将网状结构变为星状结构，使同事类之间的关系变的清晰一些。 中介者模式是一种比较常用的模式，也是一种比较容易被滥用的模式。对于大多数的情况，同事类之间的关系不会复杂到混乱不堪的网状结构，因此，大多数情况下，将对象间的依赖关系封装的同事类内部就可以的，没有必要非引入中介者模式。滥用中介者模式，只会让事情变的更复杂。 |
| 命令模式 | 意图：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；对请求排队或记录日志，以及支持可撤销的操作 动机：将”发出请求的对象”和”接收与执行这些请求的对象”分隔开来。 |
常见应用： 1、工作队列，线程池，日程安排 2、日志请求(系统恢复) 要点： 1、命令模式将发出请求的对象和执行请求的对象解耦 2、在被解耦的两者之间是通过命令对象进行沟通的。命令对象封装了接收者和一个或一组动作 3、调用者通过调用命令对象的execute()发出请求，这会使得接收者的动作被调用 4、调用者可以接受命令当作参数，甚至在运行时动态的进行 5、命令可以支持撤销，做法是实现一个undo()方法来回到execute()被执行前的状态 6、宏命令是命令的一种简单的延伸，允许调用多个命令。宏方法也可以支持撤销 7、实际操作时，很常见使用"聪明"命令对象，也就是直接实现了请求，而不是将工作委托给接受者(弊端？) 8、命令也可以用来实现日志和事物系统 |
| 责任链模式 | 使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。 | 一个纯的责任链模式要求一个具体的处理者对象只能在两个行为中选择一个：一是承担责任，而是把责任推给下家。不允许出现某一个具体处理者对象在承担了一部分责任后又 把责任向下传的情况。 在一个纯的责任链模式里面，一个请求必须被某一个处理者对象所接收；在一个不纯的责任链模式里面，一个请求可以最终不被任何接收端对象所接收。 纯的责任链模式的实际例子很难找到，一般看到的例子均是不纯的责任链模式的实现。有些人认为不纯的责任链根本不是责任链模式，这也许是有道理的。但是在实际的系统里，纯的责任链很难找到。如果坚持责任链不纯便不是责任链模式，那么责任链模式便不会有太大意义了。 |
| 装饰模式 | 又名包装(Wrapper)模式，装饰模式以对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案。 | 装饰模式与类继承的区别： 1) 装饰模式是一种动态行为，对已经存在类进行随意组合，而类的继承是一种静态的行为，一个类定义成什么样的，该类的对象便具有什么样的功能，无法动态的改变。 2) 装饰模式扩展的是对象的功能，不需要增加类的数量，而类继承扩展是类的功能，在继承的关系中，如果我们想增加一个对象的功能，我们只能通过继承关系，在子类中增加两个方法。 3) 装饰与继承比较图： 4) 装饰模式是在不改变原类文件和使用继承的情况下，动态的扩展一个对象的功能，它是通过创建一个包装对象，也就是装饰来包裹真是的对象。 5. 装饰模式把对客户端的调用委派给被装饰的类，装饰模式的关键在于这种扩展完全透明的。 |
| 策略模式 | 定义一组算法，将每个算法都封装起来，并且使他们之间可以互换。 策略模式的好处在于你可以动态的改变对象的行为。 |
策略模式属于对象行为型模式，主要针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响 到客户端的情况下发生变化。通常，策略模式适用于当一个应用程序需要实现一种特定的服务或者功能，而且该程序有多种实现方式时使用。 |
| 适配器模式 | 基于现有类所提供的服务，向客户提供接口，以满足客户的期望。
适配器模式的用意是要改变源的接口，以便于目标接口相容。缺省适配的用意稍有不同，它是为了方便建立一个不平庸的适配器类而提供的一种平庸实现。 |
适配器模式的优点 更好的复用性 系统需要使用现有的类，而此类的接口不符合系统的需要。那么通过适配器模式就可以让这些功能得到更好的复用。 更好的扩展性 在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能。 适配器模式的缺点 过多的使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是A接口，其实内部被适配成了B接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 |
| 迭代器模式 | 提供一种方法访问一个容器对象中各个元素，而又不暴露该对象的内部细节。 | 在jdk中,与迭代器相关的接口有两个:Iterator 与 Iterable Iterator:迭代器，Iterator及其子类通常是迭代器本身的结构与方法； Iterable:可迭代的，那些想用到迭代器功能的其它类，如AbstractList HashMap等，需要实现该接口。 |
| 组合模式 | 将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
对象通过实现（继承）统一的接口（抽象类），调用者对单一对象和组合对象的操作具有一致性。 |
通过实现组合模式，调用者对组合对象的操作与对单一对象的操作具有一致性。调用者不用关心这是组合对象还是文件，也不用关心组合对象内部的具体结构，就可以调用相关方法，实现功能。 |
| 观察者模式 | 定义对象间一种一对多的依赖关系，使得当每一个对象改变状态，则所有依赖于它的对象都会得到通知并自动更新。
观察者模式定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己。 |
在JAVA语言的java.util库里面，提供了一个Observable类以及一个Observer接口，构成JAVA语言对观察者模式的支持。 |
| 门面模式 | 外部与一个子系统的通信必须通过一个统一的门面对象进行。 | 门面模式的优点： ● 松散耦合 门面模式松散了客户端与子系统的耦合关系，让子系统内部的模块能更容易扩展和维护。 ● 简单易用 门面模式让子系统更加易用，客户端不再需要了解子系统内部的实现，也不需要跟众多子系统内部的模块进行交互，只需要跟门面类交互就可以了。 ● 更好的划分访问层次 通过合理使用Facade，可以帮助我们更好地划分访问的层次。有些方法是对系统外的，有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中，这样既方便客户端使用，也很好地隐藏了内部的细节。 |
| 备忘录模式 | 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存的状态。 | 备忘录对象是一个用来存储另外一个对象内部状态的快照的对象。备忘录模式的用意是在不破坏封装的条件下，将一个对象的状态捕捉(Capture)住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。备忘录模式常常与命令模式和迭代子模式一同使用。 |
| 访问者模式 | 封装某些作用于某种数据结构中各元素的操作，它可以在不改变数据结构的前提下定义作用于这些元素的新的操作。 访问者模式是对象的行为模式。访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变。 |
访问者模式的优点 好的扩展性 能够在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。 好的复用性 可以通过访问者来定义整个对象结构通用的功能，从而提高复用程度。 分离无关行为 可以通过访问者来分离无关的行为，把相关的行为封装在一起，构成一个访问者，这样每一个访问者的功能都比较单一。 访问者模式的缺点 |
| 状态模式 | 当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。 状态模式允许一个对象在其内部状态改变的时候改变其行为。这个对象看上去就像是改变了它的类一样。 |
|
| 解释器模式 | 给定一种语言，定义他的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中句子。 | |
| 享元模式 | 复用我们内存中已存在的对象，降低系统创建对象实例的性能消耗。
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();
- }
总结
如果设计模式在编码设计生涯中用得极少，主要原因是对设计模式的理解还不够，认识不到问题的存在。
因为不能正确的分析问题、认识问题，当然也不可能很好的解决问题了。