fly.net.cn

一 、工厂方法（Factory Method）模式工厂方法模式的意义是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类当中。核心工厂类不再负责产品的创建，这样核心类成为一个抽象工厂角色，仅负责具体工厂子类必须实现的接口，这样进一步抽象化的好处是使得工厂方法模式可以使系统在不修改具体工厂角色的情况下引进新的产品。二、 工厂方法模式角色与结构抽象工厂（Creator）角色：是工厂方...

策略模式的目的是定义一系列算法,把它们封装起来,并且使它们可以相互替换.本模式使得算法可以独立于它的客户而变话.以下是关于策略模式的一个小例子:package pattern.strategy;/* * 通常持有一个Strategy对象请求,也可以持有一个Strategy对象引用的聚集. * 定义一系列客户接口的方法,将客户请求委托给Strategy的算法实现 */pub...

代理模式被收录于设计模式,属于结构行模式,其目的是为其他对象提供一种代理,以控制对这个对象的访问.第一个代理模式的例子//定义代理package pattern.proxy;public class Proxy extends Subject {    /*     * 持有一个实体引用使得代理可以访问实体     */    private Subject subjec...

策略模式（Strategy Pattern）中体现了两个非常基本的面向对象设计的基本原则：封装变化的概念；编程中使用接口，而不是对接口实现。策略模式的定义如下： 定义一组算法，将每个算法都封装起来，并且使它们之间可以互换。策略模式使这些算法在客户端调用它们的时候能够互不影响地变化。 策略模式使开发人员能够开发出由许多可替换的部分组成的软件，并且各个部分之间是弱连接的关系。弱连接的特性使软件具有...

优点：这种方法的优点是，在应用程序启动时，由于不需要创建和装载所有的对象，因此加速了应用程序的启动。缺点:因为不能保证特定的应用程序对象被创建，在访问这个对象的任何地方，都需要检测确认它不是空(null)。也就是，这种检测的时间消耗是最大的缺点。应用虚拟代理模式，需要设计一个与真实对象具有相同接口的单独对象（指虚拟代理）。不同的客户对象可以在创建和使用真实对象地方用相应的虚拟对象...

这是一个很简单的模式，却被非常广泛的使用。之所以简单是因为在这个模式中仅仅使用到了继承关系。继承关系由于自身的缺陷，被专家们扣上了“罪恶”的帽子。“使用委派关系代替继承关系”，“尽量使用接口实现而不是抽象类继承”等等专家警告，让我们这些菜鸟对继承“另眼相看”。其实，继承还是有很多自身的优点所在。只是被大家滥用的似乎缺点更加明显了。合理的利用继承关系，还是能对你的系统设计起到很好的作用的。而...

登记式单例类登记式单例类是GoF 为了克服饿汉式单例类及懒汉式单例类均不可继承的缺点而设计的。本书把他们的例子翻译为Java 语言，并将它自己实例化的方式从懒汉式改为饿汉式。只是它的子类实例化的方式只能是懒汉式的， 这是无法改变的。如下图所示是登记式单例类的一个例子，图中的关系线表明，此类已将自己实例化。代码清单3：登记式单例类 ...

懒汉式单例类与饿汉式单例类相同之处是，类的构造子是私有的。与饿汉式单例类不同的是，懒汉式单例类在第一次被引用时将自己实例化。如果加载器是静态的，那么在懒汉式单例类被加载时不会将自己实例化。如下图所示，类图中给出了一个典型的饿汉式单例类实现。代码清单2：懒汉式单例类 package com.javapatterns.singleto...

单例模式的结构单例模式有以下的特点：.. 单例类只可有一个实例。.. 单例类必须自己创建自己这惟一的实例。.. 单例类必须给所有其他对象提供这一实例。虽然单例模式中的单例类被限定只能有一个实例，但是单例模式和单例类可以很容易被推广到任意且有限多个实例的情况，这时候称它为多例模式 （Multiton Pattern） 和多例类（Multiton Class），请见"专题：多例（M...

作为对象的创建模式[GOF95]， 单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。注：本文乃阎宏博士的《Java与模式》一书的第十五章。<iframe align="right" marginwidth="0" marginheight="0" src="http://www.chinabyte.com/tag/cont_flash_sof...

一、引子 　　对于系统中一个已经完成的类层次结构，我们已经给它提供了满足需求的接口。但是面对新增加的需求，我们应该怎么做呢？如果这是为数不多的几次变动，而且你不用为了一个需求的调整而将整个类层次结构统统地修改一遍，那么直接在原有类层次结构上修改也许是个不错的主意。　　但是往往我们遇到的却是：这样的需求变动也许会不停的发生；更重要的是需求的任何变动可能都要让你将整个类层次结构修改个底朝天...