ben_gmail的专栏

1.意图：定义一系列的算法，把他们一个个封装起来，并且使它们可互相替换。本模式使得算法可独立于使用它的客户而变化。2.别名：政策(policy)3.动机：有许多算法可对一个正文流进行分行。将这些算法硬编码进使用它们的类中是不可取的，其原因如下：直接包含算法会是程序变得及其复杂，这使得客户程序庞大难以维护，尤其当需要支持多种算法时问题更加严重不同的时候需要不同的算法或者说是策略，我们不想支持我们并不使用的算法增加新的算法将十分困难 我们可以定义一些类来封装不同的算法，从而避免这些问题。一个以这种方法封装的算法

<br />1.意图<br />      允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类。<br /> <br />2.描述<br />状态模式最典型的案例就是传说中的TCP网络连接案例，网络连接有三个状态，连接已建立，正在监听，连接已关闭。当对象处于不同的状态时候可以做出不同的行为。<br /> <br />state模式其实跟strategy模式非常的像。以至于网上都有对这两种模式的集中讨论。已我浅薄的理解认为state由于首先关注的是对象状态，然后再关注其行为，所以在代码实现

1.意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。2.别名：kit4.适用性：一个系统要独立于它的产品创建、组合和表示时。 一个系统要由多个产品系列中的一个来配置时。当你要强调一系列相关的产品对象的设计以便进行联合使用时。当您提供一个产品类库，而只想显示它们的接口而不是实现时。

    前言：这个模式看了很长时间，反反复复，也没理解多少，当然主要还是现实代码开发中未遇到过类似的场景是需要使用到builder模式的，可能做的项目都不够复杂吧，所以还是转载一篇我个人认为解释不错的文章来的比较实际，待自己在现实项目中遇到过后，再来写具体的感受，网上对于builder模式的例子都是汽车类例子，所以除此之外我会继续补充一个迷宫的例子加深大家影响，主要我个人认为这两个场景是使用到builder模式的典型场景。下面是我转载的原文内容：来自：http://dev.csdn.net/htmls/14

此文为半成品，待完善中...仅供自己笔记摘录单例模式的常见形式如下：  形式一：public class Singleton{private Singleton(){}        private static Singleton instance = new Singleton{};public static Singleton getInstance(){return instance;}}形式二:public class Singleton{private Singleton(){}        

何时使用bridge模式：从设计模式书上的得知较多的应用场景有：1.你不希望在抽象和它的实现部分之间有一个固定的绑定关系。例如这种情况可能是因为，在程序运行时刻实现部分应可以被选择或者切换。(一个对象的抽象对应多个行为)2.类的抽象以及它的实现都应该可以通过生成子类的方法加以扩充。这时Bridge模式使你可以对不同的抽象接口和实现部分进行组合，并分别对他们进行扩充(多个抽象与多个行为对应时且可以互相配对).3.对一个抽象的实现部分的修改应对客户不产生影响，既客户的代码不必重新编译.上面的描述中产生了两个概念

<br />由于不能收藏网址，无权发布共享。只能直接转载了....facade模式，讲的挺浅显明白的.......<br />http://www.cnblogs.com/RuiLei/archive/2007/06/21/792139.html

    该模式在java中比较典型的应用也就是jdk的io系统了    装饰模式类图好吧，其实这类图只对UML熟悉的人才有用，装饰模式有啥用？说白了就是在原来类的功能上，对这些功能做一些增强处理，当然为了增强功能而通过继承也是一种有效的方式，当然对于各种组合比较多的情况下，使用继承可能会有太多的类出现，所以就需要使用装饰模式，当然装饰模式的缺点也是显而易见的，使用上会比较麻烦。举个例子：   FileReader   StringReader   我要为这两个类的read功能增加缓存功能，如果使用继承方式，