li_w_ch的博客

传输对象模式（Transfer Object Pattern）用于从客户端向服务器一次性传递带有多个属性的数据。传输对象也被称为数值对象。传输对象是一个具有getter/setter方法的简单POJO类，它是可以序列化的，所以它可以通过网络传输。它没有任何的行为。服务器端的业务类通常从数据库读取数据，然后填充POJO，并把它发送到客户端或按值传递它。对于客户端，传输对象是只读的。客户端可以创建自己的对象，并把它传递给服务器，以便一次性更新数据库中的数值。以下是这种设计模式的实体。业务对象（Busines

服务定位器模式(Service Locator Pattern)用在我们想使用JNDI查询定位各种服务的时候。考虑到为某个服务查找JNDI的代价很高，服务定位器模式充分利用了缓存技术。在首次请求某个服务时，服务定位器在JNDI中查找服务，并缓存该服务对象。当再次请求相同的服务时，服务定位器会在它的缓存中查找，这样可以很大程度上提高应用程序的性能。以下时这种设计模式的实体。服务（Service）-实际处理请求的服务。对这种服务的引用可以在JNDI服务器中查找到。 Context/初始的Context-J

拦截过滤器模式(Intercepting Filter Pattern)用于对应用程序的请求或响应做一些预处理/后处理。定义过滤器，并在把请求传给实际目标应用程序之前应用在请求上。过滤器可以做认证/授权/记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。过滤器（Filter）-过滤器在请求处理程序执行请求之前或之后，执行某些任务。 过滤器链（Filter Chain）-过滤器链带有多个过滤器，并在Target上按照定义的顺序执行这些过滤器。 Target-Target对

前端控制器模式（Front Controller Pattern）是用来提供一个集中的请求处理机制，所有的请求都将由一个单一的处理程序处理。该处理程序可以做认证/授权/记录日志，或者跟踪请求，然后把请求传给相应的处理程序。以下是这种设计模式的实体。前端控制器(Font Controller)-处理应用程序所有类型请求的单个处理程序，应用程序可以是基于web的应用程序，也可以是基于桌面的应用程序。 调度器(Dispatcher)-前端控制器可能使用一个调度器对象来调度请求到相应的具体处理程序。 视图(

数据访问对象模式(Data Access Object Pattern)或DAO模式用于把低级的数据访问API操作从高级的业务服务中分离出来。一下是数据访问对象模式的参与者。数据访问对象接口(Data Access Object Interface)-该接口定义了一个模型对象上要执行的标准操作。 数据访问对象实体类(Data Access Object concrete class)-该类实现了上述的接口。该类负责从数据源获取数据，数据源可以是数据库，也可以是xml，或者是其他的存储机制。 模型对象

组合实体模式(Composite Entity Pattern)用在EJB持久化机制中。一个组合实体是一个EJB实体bean，代表了对象的图解。当更新一个组合实体时，内部依赖对象beans会自动更新，因为它们是有EJB实体bean管理的。一下是组合实体bean的参与者。组合实体(Composite Entity)-它是主要的实体bean。它可以是粗颗粒的，或者包含一个粗粒度对象，用于持续声明周期。 粗粒度对象(Coarse-Grained Object)-该对象包含依赖对象。它有自己的生命周期，也能管

业务代表模式(Business Delegate Pattern)用于对表示层和业务层解耦。它基本上是用来减少通信或者表示层代码中的业务层代码的远程查询功能。在业务层中能中我们有一下实体。客户端(Client)-表示层代码可以是jsp、servlet或UI java代码。 业务代表(Business Delegate)-一个为客户端实体提供的人口类，它提供了对业务服务方法的访问。 查询服务(LookUp Service)-查找服务对象负责获取相关的业务实现，并提供了业务对象对业务代表对象的访问。

MVC模式代表Model-View-Controller（模式-视图-控制器）模式。这种模式用于应用程序的分层开发。Model-模型代表一个存取数据的对象或者Java pojo。它可以带有逻辑，在数据变化时更新控制逻辑。 View-视图代表模型被包含的数据的可视化。 Controller-控制器作用于模型和视图上。它控制数据流向模型对象，并在数据变化时更新视图。它使视图与模型分离开。实现：创建一个作为模型的Student对象。StudentView是一个把学生详细信息输出到控制台的视图类，

在访问者模式(Vistior Pattern)中，使用了一个访问者类，它改变了元素类的执行方法。通过这种方式，元素的执行算法可以随着访问者改变而改变。这种类的设计模式属于行为型模式。根据模式，元素对象已接受访问者对象，这样访问者对象就可以处理元素对象的操作。模式介绍：意图：主要将数据结构与数据操作分离。主要解决：稳定的数据结构和易变的操作耦合的问题。何时使用：需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免让这些操作“污染”这些对象的类，使用访问者模式将这些封装到类中。

在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。模式介绍：意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。主要解决：一些方法通用，却在每一个子类都重新写了这一方法。何时使用：有一些通用的方法。如何解决：将这些通用算法抽象出来。关键代码：在抽象类实现，其他步骤

在策略模式(Strategy Pattern)中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为模式。在策略模式中，创建表示各种策略的对象和一个行为随着策略对象改变而改变的context对象。策略对象改变context对象的执行算法。模式介绍：意图：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。主要解决：在多种算法相似的情况下，使用if....else所带来的复杂和难以维护。何时使用：将这些算法封装成一个一个的类，任意地替换。关键代码：实现同一个接口

在空对象模式(Null Object Pattern)中，一个空对象取代NULL对象实例的检查。Null对象不是检查空值，而是反应一个不做任何动作的关系。这样的Null对象也可以在数据不可用的时候提供默认的行为。在空对象模式中，我们创建一个指定各种要执行的操作的抽象类和扩展该类的实体类，还创建一个未对该类做任何实现的空对象类，该空对象类将无缝地使用在需要检查控制的地方。实现：我们将创建一个定义操作的AbstractCustomer抽象类，和扩展了AbstractCustomer类的实体类。工厂类

在状态模式(State Pattern)中，类的行为是基于它的状态改变的。这种类型的设计模式属于行为型模式。在状态模式中，我们创建表示各种状态的对象和一个行为随着状态改变而改变的context对象。模式介绍：意图：允许对象在内部发生改变时改变它的行为，对象看起来好像修改了它的类。主要解决：对象的行为依赖于它的状态（属性），并且可以根据它的状态改变而改变它的相关行为。何时使用：代码中包含大量于对象状态有关条件语句。如何解决：将这种具体的状态类抽象出来。关键代码：通常命令模式的接口中..

当对象存在一对多关系时，则使用观察者模式(Observer Pattern)。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。模式介绍：意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖它的对象都得到通知并被自动更新。主要解决：一个对象状态的改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。何时使用：使用面向对象技术，可以将这种依赖关系弱化。关键代码：在抽象类里有一个ArrayList存放观察者们。应用实例：

备忘录模式(Memento Pattern)保存一个对象的某个状态，以便在适当的时候恢复对象。备忘录模式属于行为型模式。模式介绍：意图：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。主要解决：所谓备忘录模式就是在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。何时使用：很多时候我们总是需要记录一个兑现的内部状态，这样做的目的就是为了允许用户取消不确定或者错误的操作，能够恢复到他原先的状态。如何

中介者模式(Mediator Pattern)是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。模式介绍：意图：用一个中介对象来封装一系列的对象交互，中介者使各个对象不需要显示地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。主要解决：对象与对象直接按存在大量的关联关系，这样势必会导致系统的结构变得很复杂，同时若一个对象发生改变，我们也需要跟踪与之相关联的对象，同时做出相应的处理。

迭代器模式(Iterator Pattern)是java和.net编程环境中非常常用的设计模式。这种模式用于顺序访问集合对象的元素，不需要知道集合对象的底层表示。它属于行为模式。模式介绍：意图：提供一种方法顺序访问一个聚合对象的各个元素，而又无需暴露该对象的内部表示。主要解决：不同的方式来遍历整个整合对象。何时使用：遍历一个聚合元素。关键代码：定义接口：hasNext,next。应用实例：java中的iterator。优点：它支持以不同的方式遍历一个聚合对象。 迭代器简化了

解释器模式(Interpreter Pattern)提供了评估语言的语法或表达的方式，它属于行为模式。这种模式实现了一个表达式接口，该接口解释一个特定的上下文。这种模式被用在SQL解析、符号处理引擎等。模式介绍：意图：给定一个语言，定义它的文法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子。主要解决：对于一些固定文法构建一个解释句子的解释器。何时使用：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，

命令模式(Command Pattern)是一种数据驱动的设计模式，它属于行为型模式。请求以命令的形式包裹在对象中，并传给调用对象。调用对象寻找可以处理该命令的合适的对象，并把该命令传给相应的对象，该对象执行命令。模式介绍：意图：将一个请求封装成一个对象，从而可以用不同的请求对客户进行参数化。主要解决：在软件系统中，行为请求者雨行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事物等处理时，这种无法抵御变化的紧耦合的设计就不太合适。如何解决：通过调用者调用接收

责任链模式(Chain of Resposibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为模式。这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的请求传给下一个接收者，一次类推。模式介绍：意图：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。主要解决：职责链上的处理

在代理模式(Proxy Pattern)中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。模式介绍：意图：为其他对象提供一种代理以控制对这个对象的访问。主要解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些曹祖需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象

享元模式(Flyweight Pattern)主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型设计模式属于结构型模式，它提供了减少对象数量从而来改善应用所需的对象结构的方式。享元模式尝试重用现有的同类对象，如果未找到匹配的对象，则创建新对象。模式介绍：意图：运用共享技术有效地支持大量细粒度的对象。主要解决：在有大量对象时，有可能胡造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。何时使用：系统中有大量对象。 这

外观模式(Facade Pattern)隐藏系统的复杂性，并向客户端提供了一个客户端可以访问的系统接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。这种模式涉及到一个单一的类，改类提供了客户端请求的简化方法和对现有系统类方法的委托调用。模式介绍：意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。何时使用：客户端不需要

装饰器模式(Decorator Pattern)允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。模式介绍：意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。主要解决：一般的，为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。何时使用：在不

组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。模式介绍：意图：将对象组合成树形结构以表示“部分-整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可

桥接(Bridge)是用于把抽象化与现实化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。比如，可以使用相同的抽象类方法但是不同的桥接实现类，来画出不同颜色的圆。模式介绍：意图：将抽象部分与实现部分分离，使它们可以独立的变化。主要解决：在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。何时使用

适配器模式(Adapter Pattern)是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。比如，读卡器是作为内存卡和笔记本之间的适配器。将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。模式介绍：意图：将一个类的接口转换成客户系统的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。主要解决：主要解决在软件系统中，常常要将一些

原型模式(Prototype Pattern)是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建了对象的最佳方式。这种模式是实现了一个原型接口，该接口是用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。模式介绍：意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。主要解

建造者模式（Builder Pattern）使用多个简单的对象一步一步构建成一个复杂的对象。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。一个Builder类会一步一步构造最终的对象。该Builder类是独立于其他对象的。模式介绍：意图：将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。主要解决：主要解决在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的

1、懒汉模式，线程不安全是否Lazy初始化：是 是否多线程安全：否 实现难度：易描述：这种方式是最基本的实现方式，这种实现最大的问题就是不支持多线程。因为没有加锁synchronized，所以严格意义上它并不算单例模式。这种方式lazy loading很明显，不要求线程安全，在多线程不能正常工作。public class Singleton{ private static Singleton instance; private Singleton(){} p

单例模式是java中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。这种模式涉及到一个单一的类，该负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象方式，可以直接访问，不需要实例化该类的对象。注意：单例类只能有一个实例。 单例类必须自己创建自己的唯一实例。 单例类必须给所有其他对象提供这一实例。模式介绍：意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。主要解决：一个全局使用的类频繁地创建于销毁。何时使

抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。模式介绍：意图：提供一个创建一些列相关或相互依赖对象的接口，而无需指定它们具体的类。主要解决：主要解决接口选择的问题。何时使用：系统的产品有多于一个的产品族，而系统之消费其中某一族的

工厂模式（Factory Pattern）是java中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。在工厂模式中，我们在创建对象时不会对客户端暴露船舰逻辑，并且是通过使用一个共同的接口来指向新创建的对象。模式介绍：意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。主要解决：主要解决接口选择的问题。何时使用：明确地计划不同条件下创建不同实例时。如何解决：让其子类实现工厂接口，返回的也是一个抽象