package com.javapatterns.factorymethod;
public class BadPlantException extends Exception
{
public BadPlantException(String msg)
{
super(msg);
}
}
代码清单6. 例外类 BadPlantException。
工厂方法模式应该在什么情况下使用
既然工厂方法模式与简单工厂模式的区别很是微妙，那么应该在什么情况下使用工厂方法模式，又应该在什么情况下使用简单工厂模式呢？
一般来说，如果你的系统不能事先确定那一个产品类在哪一个时刻被实例化，从而需要将实例化的细节局域化，并封装起来以分割实例化及使用实例的责任时，你就需要考虑使用某一种形式的工厂模式。
在我们的小花果园系统里，我们必须假设水果的种类随时都有可能变化。我们必须能够在引入新的水果品种时，能够很少改动程序，就可以适应变化以后的情况。因此，我们显然需要某一种形式的工厂模式。
如果在发现系统只用一个产品类等级(hierarchy)就可以描述所有已有的产品类，以及可预见的未来可能引进的产品类时，简单工厂模式是很好的解决方案。因为一个单一产品类等级只需要一个单一的实的工厂类。
然而，当发现系统只用一个产品类等级不足以描述所有的产品类,包括以后可能要添加的新的产品类时，就应当考虑采用工厂方法模式。由于工厂方法模式可以容许多个实的工厂类，以每一个工厂类负责每一个产品类等级，因此这种模式可以容纳所有的产品等级。
在我们的小花果园系统里，不只有水果种类的植物,而且有蔬菜种类的植物。换言之，存在不止一个产品类等级。而且产品类等级的数目也随时都有可能变化。因此，简单工厂模式不能满足需要，为解决向题,我们显然需要工厂方法模式。
关于模式的实现
在实现工厂方法模式时，有下面一些值得讨论的地方。
第一丶在图四的类图定义中，可以对抽象工厂(Creator) 做一些变通。变通的种类有
抽象工厂(Creator) 不是接口而是抽象类。一般而言，抽象类不提供一个缺省的工厂方法。 这样可以有效地解决怎样实例化事先不能预知的类的问题。
抽象工厂(Creator) 本身是一个实类，并提供一个缺省的工厂方法。 这样当最初的设计者所预见的实例化不能满足需要时，后来的设计人员就可以用实工厂类的factory() 方法来置换(Override))父类中factory()方法。
第二丶在经典的工厂方法模式中，factory()方法是没有参量的。在本文举例时加入了参量，这实际上也是一种变通。
第三丶在给相关的类和方法取名字时，应当注意让别人一看即知你是在使用工厂模式。
COM技术架构中的工厂方法模式
在微软(Microsoft)所提倡的COM(Component Object Model)技术架构中, 工厂方法模式起着关键的作用。
在COM架框里,Creator接口的角色是由一个叫作IClassFactory的COM接口来担任的。而实类ConcreteCreator的角色是由实现IClassFactory接口的类CFactory(见下图)来担任的。一般而言,对象的创立可能要求分配系统资源,要求在不同的对象之间进行协调等等。因为IClassFactory的引进,所有这些在对象的创立过程中出现的细节问题, 都可以封装在一个实现IClassFactory接口的实的工厂类里面。这样一来, 一个COM架构的支持系统只需要创立这个工厂类CFactory的实例就可以了。
图6. 微软(Microsoft)的COM(Component Object Model)技术架构是怎样工作的。
在上面的序列活动(Sequence Activity)图中,用户端调用COM的库函数CoCreateInstance。 CoCreateInstance在COM架框中以CoGetClassObject实现。 CoCreateInstance会在视窗系统的Registry里搜寻所要的部件(在我们的例子中即CEmployee)。如果找到了这个部件,就会加载支持此部件的DLL。当此DLL加载成功后, CoGetClassObject就会调用DllGetClassObject。后者使用new操作符将工厂类CFactory实例化。
下面,DllGetClassObject会向工厂类CFactory搜询IClassFactory接口,返还给CoCreateInstance。 CoCreateInstance接下来利用IClassFactory接口调用CreateInstance函数。此时,IClassFactory::CreateInstance调用new操作符来创立所要的部件(CEmployee)。此外,它搜询IEmployee接口。在拿到接口的指针后, CoCreateInstance释放掉工厂类并把接口的指针返还给客户端。
客户端现在就可以利用这个接口调用此部件中的方法了。
EJB技术架构中的工厂方法模式
升阳(Sun Microsystem)倡导的EJB(Enterprise Java Beans)技术架构是一套为爪哇语言设计的, 用来开发企业规模应用程序的组件模型。我们来举例看一看EJB架构是怎样利用工厂方法模式的。请考察下面的序列活动图。
图7. 在升阳所提倡的EJB技术架构中, 工厂方法模式也起着关键的作用
在上面的图中,用户端创立一个新的 Context 对象,以便利用 JNDI 伺服器寻找 EJBObject。在得到这个 Context 对象后,就可以使用 JNDI 名, 比如"Employee", 来拿到 EJB 类 Employee 的 Home 接口。使用 Employee 的 Home 接口,客户端可以创立 EJB 对象,比如 EJB 类 Employee 的实例 emp, 然后调用 Employee 的各个方法。
// 取到 JNDI naming context
Context ctx = new InitialContext ();
// 利用ctx 索取 EJB Home 接口
EmployeeHome home = (EmployeeHome)ctx.lookup("Employee");
// 利用Home 接口创立一个 Session Bean 对象
// 这里使用的是标准的工厂方法模式
Employee emp = home.create (1001, "John", "Smith");
// 调用方法
emp.setTel ("212-657-7879");
代码清单7. EJB架构中,Home接口提供工厂方法以便用户端可以动态地创立EJB类Employee的实例。
JMS技术架构中的工厂方法模式
JMS定义了一套标准的API,让爪哇语言程序能通过支持JMS标准的MOM(Message Oriented Middleware 面向消息的中间伺服器)来创立和交换消息(message)。我们来举例看一看JMS(Java Messaging Service)技术架构是怎样使用工厂方法模式的。
图8. 在JMS技术架构中, 工厂方法模式无处不在
在上面的序列图中,用户端创立一个新[1] [2] 下一页
|
|
