3-抽象工厂模式.doc

意图提供一个创建一系列相关活相互依赖对象的接口，而无需指定他们具体的类。(G4)任务假设我们需要进行各种数据库操作，可是我们有很多的选择啊，JDBC，Hibernate，Ibatis等等。本来选择一个就OK了，可是变态的Boss为了炫耀我们的技术如何如何强大，竟说我们能够无成本地在这三个解决方案间切换。这下系统该怎么设计呢？或许你已经注意到每种解决方案自身都是完备而独立的，不错，这便是解决问题的切入点。提供一套解决方案公有行为的接口，各个解决方案分别实现这些接口，同时建立一个创建各个解决方案的工厂(Factory)。这不就完成任务了吗？哈哈。首先我们从使用者的角度出发，总结出一套数据库操作的方法，在这里我们称为Service。假设我们只需要一个行为，就是work()，内容是打印出这是来自哪个解决方案。java 代码1. /* 2. *业务类接口 3. */ 4. publicinterfaceService 5. /* 6. *运行业务 7. */ 8. voidwork(); 9. 然后我们根据这个接口分别实现各个解决方案的相应实现。java 代码1. /* 2. *A体系中的业务实现 3. */ 4. publicclassServiceAimplementsService 5. 6. publicvoidwork() 7. System.out.println(这是A体系中业务。); 8. 9. java 代码1. /* 2. *B体系中的业务实现 3. */ 4. publicclassServiceBimplementsService 5. 6. publicvoidwork() 7. System.out.println(这是B体系中业务。); 8. 9. 大概各位都碰到过需求不断变更，Service不断增加的情况吧。只有一个Service可不够用啊，保不准等会儿Boss就调研回来，需要新增加一个Service2，Service3.ServiceN。如果都写到Service接口里，那可是变成巨无霸了。汉堡包巨无霸我喜欢，代码巨无霸我可就不喜欢了。于是给这些Service建立一个工厂(Factory)，以方便地创建各种Service。那么我们首先来建立一个Factory的接口类。java 代码1. /* 2. *工厂接口 3. */ 4. publicinterfaceFactory 5. /* 6. *建立创建Service的抽象接口，由各实现的工厂来创建具体的Service 7. */ 8. ServicecreateService(); 9. 下面就来实现各个解决方案的工厂。java 代码1. /* 2. *具体的实现工厂A 3. */ 4. publicclassFactoryA implements Factory 5. 6. publicServicecreateService() 7. /创建本体系中的Service实现 8. returnnewServiceA(); 9. 10. java 代码1. /* 2. *具体的实现工厂B 3. */ 4. publicclassFactoryB implements Factory 5. 6. publicServicecreateService() 7. /创建本体系中的Service实现 8. returnnewServiceB(); 9. 10. 或许各位看官会说这不就是工厂模式嘛，怎么又在前面加上“抽象”二字，难不成是故弄玄虚？非也非也。前头说过了，我们解决问题的切入点是“每种解决方案自身都是完备而独立的”，所以这些具体的各种解决方案的工厂对Consumer也应该是透明的。于是我们给这些工厂(解决方案)加上一个工厂，也就是我们通过这个工厂来生成一整套的解决方案。这个工厂便是我们要说的AbstractFactory。java 代码1. /* 2. *抽象工厂 3. */ 4. publicclassAbstractFactory 5. /* 6. *根据不同的体系要求创建出不同的业务工厂 7. * 8. *paramfactoryName 9. *return 10. */ 11. publicstaticAbstractFactorygetFactory(StringfactoryName) 12. AbstractFactoryist=null; 13. if(factoryName.equalsIgnoreCase(A) 14. ist=newFactoryA(); 15. elseif(factoryName.equalsIgnoreCase(B) 16. ist=newFactoryB(); 17. 18. returnist; 19. 20. 本着重构的精神，也为了给点事AbstractFactory做，我便把它和接口Factory合而为一，成为一个抽象类。大概这便是这种设计模式名字的由来吧。呵呵。java 代码1. /* 2. *抽象工厂 3. */ 4. publicabstractclassAbstractFactory 5. /* 6. *根据不同的体系要求创建出不同的业务工厂 7. * 8. *paramfactoryName 9. *return 10. */ 11. publicstaticAbstractFactorygetFactory(StringfactoryName) 12. AbstractFactoryist=null; 13. if(factoryName.equalsIgnoreCase(A) 14. ist=newFactoryA(); 15. elseif(factoryName.equalsIgnoreCase(B) 16. ist=newFactoryB(); 17. 18. returnist; 19. 20. 21. /* 22. *建立创建Service的抽象接口，由各实现的工厂来创建具体的Service 23. */ 24. publicabstractServicecreateService(); 25. 相应的，FactoryA和FactoryB修改为java 代码1. publicclassFactoryAextendsAbstractFactory 2. . 3. 4. 5. publicclassFactoryBextendsAbstractFactory 6. . 7. 这样，各种解决方案间的切换便十分容易了。java 代码1. /* 2. *业务的消费者 3. * 4. *author聪明的笨蛋 5. * 6. */ 7. publicclassConsumer 8. publicvoidwork() 9. Serviceservice=null; 10. 11. /实现A体系中的业务 12. service=AbstractFactory.getFactory(A).createService(); 13. service.work(); 14. 15. /实现B体系中的业务 16. service=AbstractFactory.getFactory(B).createService(); 17. service.work(); 18. 19. 20. /运行 21. publicstaticvoidmain(Stringargs) 22. Consumercsm=newConsumer(); 23. csm.work(); 24. 25. 恩，Mission completed！剩下的就是各个解决方案的实现了，哈哈。那些工作就让，就让.没有人做，还是我做吧.谁叫俺是小弟呢。唉小结正如我上面举的这个例子，抽象工厂模式主要适用于需要提供若干种不同实现体系，但又要求有相同处理要求的时候。如Portal技术中，各种Portlet便是不同的体系，但我们在处理Portal的时候都是把他们统一当作Portlet实现，同样这种解决问题的思路可以用在SOA中。这种设计模式大多出现在各个系统进行集成的时候。题外话对于上面的抽象工厂中，AbstractFactory依赖于其各子类Factory，这是不合适的。因为这样一来，我们的工程中如果只使用其中一种Factory时，却不得不背上其他用不上的Factory。在这里多做一些改进工作，使用类似于spring中管理bean的方式，对各Factory进行管理。首先我们需要规定好一种管理格式，在这里以xml为例吧。xml 代码1. 2. 3. 4. 这样，我们可以在AbstractFactory加入一个读配置的方法getXmlClass，通过输入id值来读出其对应的class名。这样，我们的AbstractFactory变成java 代码1. publicabstractclassAbstractFactory 2. 3. /读取配置文件 4. privatestaticStringgetXmlClass(Stringid) 5. . 6. 7. 8. publicstaticAbstractFactorygetFactory(StringfactoryName) 9. AbstractFactoryist=null; 10. StringclassName=getXmlClass(factoryName); 11. try 12. ist=(AbstractFacto