在开发类的过程中，开发人员通常要为这个类提供若干个构造器，以方便类型使用者实例化该类。在某此情况下，你也许希望避免类的用户直接调用构造器。此时，可使用Builder、Factory Method 以及Abstract Factory 模式等构造型模式,这三种模式都不充许类的用户直接调用类的构造器，而是为用户另外提供了一套构建方法，用于实例化适当的类。Prototype模式也向用户隐藏了类型创建方法，不过它采用的方法与前面的三种构造型模式不同。

Prototype（原型）模式不通过实例化类来创建一个新的未初始化的实例，而是通过复制一个现有的对象来生成新的对象。

优点：
1、可以在不创建新类的前提下创建新工厂；甚至可以在运行时创建一个GUI。
2、可以这样创建一个新工厂：复制一个老工厂，然后按照需求进行适当调整。比如，我们可以创建一个新的GUI工具集，与老工具集的差别只在于字体不同。借助于原型方法，新工厂的按钮和其他控制可以从以前的工厂“继承”值，如颜色。
缺点：
1、该模式方法充许我们修改每个工厂的属性值，诸如颜色和字体，但是不充许我们创建具有不同行为的新工具集。
2、终止UI工具集进一步扩充的原因不清楚；为什么进一步扩充存在问题？我们必须把工具集初始化代码放在建议的类的静态方法中。这种方法并不能真正减少需要管理的代码的数量。
3、不充许新对象拥有与父对象不同的方法。

下面我就结合一个例子来帮助大家理解Prototype（原型）模式

阅读全文

作为类的开发者，我们通常会在类中提供构造器以便于客户代码实例化该类。然而，有时候类比较多时，客户代码并不清楚该对哪一个类进行实例化。

Factory Method（工厂方法）模式的主要意图是用于创建对象的接口，同时控制对哪个类进行实例化。

在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一个产品类被实例化这种细节。这使得工厂方法模式可以允许系统在不修改工厂角色的情况下引进新产品。在Factory Method模式中，工厂类与产品类往往具有平行的等级结构，它们之间一一对应。

下面我给出一个例子来帮助大家理解Factory Method（工厂方法）模式

阅读全文

当构造某对象时，也许无法保证总能事先获知对象的所有所需要的信息。尤其是，有时候目标对象的构造器的参数只能逐步获取，我们希望能够一步一步地构造目标对象，常见情况比如解析器和用户接口。或者，当对类的重点难以很好把握并且类的构造过程相当复杂时，你也许希望简化类的规模。这时候就可以使用Builder模式。

Builder（生成器）模式的意图是把构造对象实例的代码逻辑移到要实例化的类的外部。

使用Builder模式而获益的常见情况是定义所期望对象的数据被嵌套在文本字符串中。随着逐步查询代码或者说解析数据的过程中，你需要随着发现过程来保存这些数据。不管解析器是基于XML的还是手工执行的，最初也许不足以拥有构造合法目标对象所需要的全部数据。对这种情况，Builder模式的处理方式是把数据存储在临时对象中，直到程序拥有构造所需要的全部数据，这时候才查询存储的临时对象来构造目标对象。

下面我就结合一个例子来帮助大家理解Builder（生成器）模式：

阅读全文

Flyweight（享元）模式可实现客户代码之间的对象共享，创建共享对象的职责，这一点是普通对象不具备的。一般的对象不必关心共享职责，任何时刻最多只能有一个客户代码引用它，其他时刻可以是其他某一客户代码引用。如果多个客户代码引用同一个对象，那么当某个客户代码修改了该对象的状态时，该对象是不会通知其他客户代码的。然而，有时候，我们需要让多个客户代码共享访问同一个对象。

当我们必须管理成千上万个小型对象的时候，我们需要让多个客户代码共享一个对象。在这种情况下，为了提高应用程序的性能，需要考虑这些细粒度的对象在多个客户代码之间的安全共享访问问题。

Flyweight（享元）模式的主要意图在于通过共享来支持大量的细粒度对象的使用效率。

下面我就结合一个简单的例子来为大家讲解

阅读全文

这里我给大家介绍的是一个用Asp写的分组分页程序，非常的类似于百度、和Google的分页，但是也有一定的区别。我的分页程序效果是这样的：

首先，默认显示的是1--11页
01 02 03 04 05 06 07 08 09 10 11

然后，当你点击到11页以后，分页效果变成这样
06 07 08 09 10 11 12 13 14 15 16

其实这种分组分页的原理我是通过一个分页函数来完成的，主要涉及的只有3个参数，我会在下面调用的时候讲解的。下面请看代码：

分页函数如下：
阅读全文

面向对象开发通常希望明确和减少对象间的责任，从而降低对象之间的耦合程度。这样我们的系统更加容易修改，同时也可降低产生缺陷的风险。如果我们将若干对象按照某种层次结构进行组织，比如组织为类责任链，客户代码就有可能不必事先了解自己将使用哪一个类。在这种情况下，链中的每个对象都有一个方法，当客户端代码调用该方法的时候，这些对象要么执行该方法，要么沿着这条链转发该方法调用请求。

Chain of Responsibility（责任链）模式可让每个对象都有一次机会决定自己是否处理请求，以便于避免请求的发送者与其接收者之间的耦合

Chain of Responsibility（责任链）模式的三个主要应用：
1、最常用于带组合的对象模型中
2、按照某种循环顺序轮流为客户程序提供服务的一组对象，这些对象形成了一个环状的链。如果某个对象在一定时间内或由于某种原因无法为客户程序提供服务时，则将请求自动转发给环上的其他对象，以保证对客户的服务。
3、流水线处理，比如对用户的输入，使用一些解析器按先后顺序轮流解析用户输入的文本，这些解析器也形成一个链。

下面我就通过一个例子来为大家演示Chain of Responsibility（责任链）模式

阅读全文

普通对象所需要完成的任务是通过公共接口为外界提供自己所承诺的服务。然而，有时候合法的对象可能会因为各种原因而无法完成自己常规的任务。尤其是当对象需要很长时间才能载入内存、对象正运行在另一台计算机上或者需要获取对象消息的时候，这种情况就会频繁出现。在这种情况下，我们可以使用一个代理对象，由它来承担客户期待的责任，并将请求转发给其背后的目标对象。

Proxy（代理）模式的意图在于为对象提供一个代理或者占位(placeholder)来控制对该对象的访问。

Proxy（代理）模式的两个主要应用：
1、授权机制不同级别的用户对同一对象拥有不同的访问权利。
2、某个客户端不能直接操作到某个对象,但又必须和那个对象有所互动.
举例两个具体情况:
（1）如果那个对象是一个是很大的图片，需要花费很长时间才能显示出来，那么当这个图片包含在文档中时，使用编辑器或浏览器打开这个文档，打开文档必须很迅速，不能等待大图片处理完成，这时需要做个图片Proxy来代替真正的图片。
（2）如果那个对象在Internet的某个远端服务器上，直接操作这个对象因为网络速度原因可能比较慢，那我们可以先用Proxy来代替那个对象。
总之，对于开销很大的对象，只有在使用它时才创建，这个原则可以为我们节省很多宝贵的Java内存。所以，有些人认为Java耗费资源内存，我以为这和程序编制思路也有一定的关系。

下面我就用Proxy（代理）模式做个加载图片的小例子
阅读全文

通常，面向对象的软件开发要求尽可能细致地分配责任，从而使每个对象都能够独立完成自己的任务。Observer模式通过尽可能缩小一个对象应对其他对象承担的责任范围来支持这种责任分配。而 Singleton模式将责任集中于其他对象都可以访问和复用的某个特定对象中。与Singleton模式类似的是，Mediator模式也对责任进行了集中，不过这种模式只是对某个特定对象集合的责任进行集中，而不是对整个系统的其他所有对象的责任进行集中。

如果对象群组中的交互错综复杂，而每个对象都需要了解本集合中其他每个对象的情况，那么这个时候采用一个核心机构来负责控制它们之间的交互将非常有用。当这些相关对象之间的交互独立于对象的其他行为的时候，对责任进行集中也很有用。

Mediator（中介者）模式的意图是定义一个对象，该对象将对象集合之间的交互封装起来。利用该模式可以降低对象之间的耦合程度，避免对象之间的显式引用，还可以让对象间的交互独立变化。

下面给出一个具体的例子为大家演示Mediator（中介者）模式

以下是Test.java代码： public class Test  {     public static void main(String[] args) {         Mediator myMed = new ConcreteMediator();         ColleagueA a = new ColleagueA(myMed);         ColleagueB b = new ColleagueB(myMed);         ColleagueC c = new ColleagueC(myMed);         a.Change();         b.Change();         c.Change();     } }

阅读全文