深入浅出设计模式电子书，帮助您分析编辑的设计思路，从程序代码的构件模型到定义结构，本书都为您提供了详细的介绍，让您在构建程序框架的时候可以丰富自己的想象力，每一个程序在编辑的之前都需要认真的构想每一项数据，一款好的软件不仅在内容上丰富、实用，还要看程序员的编辑思维，有的设计的数据非常庞大，有的程序员通过简单的代码命令就能设计出软件，这跟程序的构件模式和开发的思维是由很大关系的，这款书籍就是训练您编辑思维的方法，需要的朋友可以下载观看。
软件功能
工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来， 达到提高灵活性的目的。 工厂模式在《Java 与模式》中分为三类：
1）简单工厂模式（Simple Factory）
2）工厂方法模式（Factory Method）
3）抽象工厂模式（Abstract Factory） 这三种模式从上到下逐步抽象，并且更具一般性。 GOF 在《设计模式》一书中将工厂模式分为两类：工厂方法模式（Factory Method）与 抽象工厂模式（Abstract Factory）。将简单工厂模式（Simple Factory）看为工厂方法模式的 一种特例，两者归为一类。 两者皆可，在本文使用《Java 与模式》的分类方法。下面来看看这些工厂模式是怎么 来“治病”的。
三、简单工厂模式 简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存 在的目的很简单：定义一个用于创建对象的接口。 先来看看它的组成：
1) 工厂类角色：这是本模式的核心，含有一定的商业逻辑和判断逻辑。在java中它往往由 一个具体类实现。
2) 抽象产品角色：它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽 象类来实现。
3) 具体产品角色：工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。
软件特色
工厂方法模式 工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这 样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分 担。 你应该大致猜出了工厂方法模式的结构，来看下它的组成：
1) 抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须 实现的接口或者必须继承的父类。在 java 中它由抽象类或者接口来实现。
2) 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体 产品的对象。
3) 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类 或者接口来实现。 4) 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类 来实现。 用
使用方法
那么简单工厂模式怎么来使用呢？我们就以简单工厂模式来改造暴发户坐车的方式 ——现在暴发户只需要坐在车里对司机说句：“开车”就可以了。
将本程序空缺的其他信息填充完整后即可运行。如果你将所有的类放在一个文件中，请 不要忘记只能有一个类被声明为 public。本程序在 jdk1.4 下运行通过。 程序中各个类的关系表达如下：
工厂方法模式使用继承自抽象工厂角色的多个子类来代替简单工厂模式中的“上帝类”。 正如上面所说，这样便分担了对象承受的压力；而且这样使得结构变得灵活起来——当有新 的产品（即暴发户的汽车）产生时，只要按照抽象产品角色、抽象工厂角色提供的合同来生 成，那么就可以被客户使用，而不必去修改任何已有的代码。可以看出工厂角色的结构也是 符合开闭原则的！
我们还是老规矩，使用一个完整的例子来看看工厂模式各个角色之间是如何来协调的。 话说暴发户生意越做越大，自己的爱车也越来越多。这可苦了那位司机师傅了，什么车它都 要记得，维护，都要经过他来使用！于是暴发户同情他说：看你跟我这么多年的份上，以后 你不用这么辛苦了，我给你分配几个人手，你只管管好他们就行了！于是，工厂方法模式的 管理出现了。代码如下：
可以看出工厂方法的加入，使得对象的数量成倍增长。当产品种类非常多时，会出现大 量的与之对应的工厂对象，这不是我们所希望的。因为如果不能避免这种情况，可以考虑使 用简单工厂模式与工厂方法模式相结合的方式来减少工厂类：即对于产品树上类似的种类 （一般是树的叶子中互为兄弟的）使用简单工厂模式来实现。
抽象工厂模式 先来认识下什么是产品族： 位于不同产品等级结构中，功能相关联的产品组成的家族。 还是让我们用一个例子来形象地说明一下吧。
抽象工厂角色： 这是工厂方法模式的核心，它与应用程序无关。是具体工厂角色必须 实现的接口或者必须继承的父类。在 java 中它由抽象类或者接口来实现。 2) 具体工厂角色：它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体 产品的对象。在 java 中它由具体的类来实现。 3) 抽象产品角色：它是具体产品继承的父类或者是实现的接口。在 java 中一般有抽象类 或者接口来实现。 4) 具体产品角色：具体工厂角色所创建的对象就是此角色的实例。在 java 中由具体的类 来实现。 类图如下：
相关介绍
多个虚拟机 当系统中的单例类被拷贝运行在多个虚拟机下的时候，在每一个虚拟机下都可以创建一 个实例对象。在使用了 EJB、JINI、RMI 技术的分布式系统中，由于中间件屏蔽掉了分布式 系统在物理上的差异，所以对你来说，想知道具体哪个虚拟机下运行着哪个单例对象是很困 难的。 因此，在使用以上分布技术的系统中，应该避免使用存在状态的单例模式，因为一个有 状态的单例类，在不同虚拟机上，各个单例对象保存的状态很可能是不一样的，问题也就随 之产生。而且在 EJB 中不要使用单例模式来控制访问资源，因为这是由 EJB 容器来负责的。 在其它的分布式系统中，当每一个虚拟机中的资源是不同的时候，可以考虑使用单例模式来 进行管理。
多个类加载器 当存在多个类加载器加载类的时候，即使它们加载的是相同包名，相同类名甚至每个字 节都完全相同的类，也会被区别对待的。因为不同的类加载器会使用不同的命名空间 （namespace）来区分同一个类。因此，单例类在多加载器的环境下会产生多个单例对象。
也许你认为出现多个类加载器的情况并不是很多。其实多个类加载器存在的情况并不少 见。在很多 J2EE 服务器上允许存在多个 servlet 引擎，而每个引擎是采用不同的类加载器的； 浏览器中 applet 小程序通过网络加载类的时候，由于安全因素，采用的是特殊的类加载器， 等等。 这种情况下，由状态的单例模式也会给系统带来隐患。因此除非系统由协调机制，在一 般情况下不要使用存在状态的单例模式。
错误的同步处理 在使用上面介绍的懒汉式单例模式时，同步处理的恰当与否也是至关重要的。不然可能 会达不到得到单个对象的效果，还可能引发死锁等错误。因此在使用懒汉式单例模式时一定 要对同步有所了解。不过使用饿汉式单例模式就可以避免这个问题。
子类破坏了对象控制 在上一节介绍最后一种扩展性较好的单例模式实现方式的时候，就提到，由于类构造函 数变得不再私有，就有可能失去对对象的控制。这种情况只能通过良好的文档来规范。
串行化（可序列化） 为了使一个单例类变成可串行化的，仅仅在声明中添加“implements Serializable”是不 够的。因为一个串行化的对象在每次返串行化的时候，都会创建一个新的对象，而不仅仅是 一个对原有对象的引用。为了防止这种情况，可以在单例类中加入 readResolve 方法。关于 这个方法的具体情况请参考《Effective Java》一书第 57 条建议。 其实对象的串行化并不仅局限于上述方式，还存在基于 XML 格式的对象串行化方式。 这种方式也存在上述的问题，所以在使用的时候要格外小心。
∨ 展开