抽象工厂
你是这个工厂的BOSS，而不是一个小车间主任。你必须具备掌控全局的权力与能力
真的该使用它吗？
个人感觉抽象工厂是诸多设计模式中最为“宏伟”的一个模式，同时也是一个相对复杂的模式。
所以请首先注意，你所面临的功能需求/非功能需求，是否确实有以下“一横一竖”
（若不明白，我之后会有详细实例说明）
一横：横向扩展，比如平级业务场景，平级的项目部署，未来还会继续在这个基础上进行平级横向扩展
一竖：纵向产品族，每个横向的工厂下面有一套规整统一，扩展性较少的产品。（纵向扩展的难度，将比横向扩展要大）
------【实际应用举例说明】--------------------
我的所有举例均尽可能取自于生产项目中的实际运用，出于篇幅考虑做一定程度删减
现在有如下一个业务平台，将至少要对接3个终端接入，PC，手机与开放API，而这3个终端都具有4个对身份认证要求严格的业务，“登录”，“支付”，“退款”，“提现”。
从系统架构上来说，整套系统采用分布式的设计，3个终端的控制层与核心业务处理层相分离，所以，3个平级的控制层需要4个认证处理完成的结果生成Bean，给到核心业务处理层进行处理，粗略架构图如下图：
架构图
一横：三个平级的平台控制层，未来或许会扩展更多
一竖：四个业务处理模块，而且比较长时间里纵向不会发生太多的变化
然后我们把抽象工厂的两个核心点“工厂”与“产品”拼装上来，看看效果如何
“伪类图”
大概的样子出来了吧
再来套用标准的抽象工厂类图来看一下（由于4个方法太占篇幅，就只以两个举例了）
抽象工厂模式标准类图
很显然Bean就是Product角色了，而client角色就是我们的核心业务层的实现类了，他们在拿到验证结果Bean后进行具体的业务处理
具体的代码我正在整理中，完成了我会在放出源码文件，同时也会在github上放一份
做到这里，你可以再在立体化思考一下，不用总想这个代码是你一个人开发的：
假设你是这个项目的架构设计师，你需要统筹control层与service层的开发接口与规范，那么如上面的这种设计，当你将任务发放给下属的程序猿们时，他们能否在你划定的区域内进行良好的业务处理和扩展呢？ 如果你觉得可以，那说明这个抽象工厂咱搭建得没问题。
-------------总结思考-----------------------------------------
来看看这么做了会有怎么样的影响？
如果在PC、手机、API的平级又出现了另外一个终端，怎么办？很好办，就按照这个标准的工厂接口以及产品的划分进行具体的实现就好了
如果是要纵向新增一个产品呢，比如现在进行一个抽奖活动，在各个平台均出现了一个“抽奖身份验证”的需求，这样一来怎么办呢？好像，是不是必须得从顶头的工厂开始修改了...？貌似是一个悲伤的故事...
所以这样一来，可以发现一个现象：抽象工厂结构规范严谨，在横向扩展上优势明显，但在纵深上产品扩展显得有些力不从心。
抽象工厂，大家伙，使用在大场面，所以，你可以再看看，你的系统架构/功能点，有没有“一横一竖”的需求呢？
其他实际运用场景（不断更新补充）：
1. 面对不同的数据库(Factory)，创建连接、连接池、预处理语句(Product族)等等2. Spring源码结构中有用到，具体忘记了
以上均为我个人在参考一定书籍以及网上文章后总结的观点，一定还有欠妥之处，只求尽量简单与实际的分享给大家，欢迎讨论拍砖。
参考书籍：
[1]陈臣，王斌．研磨设计模式．清华大学出版社．2010．
[2]Erich Gamma,Richard Helm,Ralph Johnson,John Vlissides，设计模式：可复用面向对象软件的基础. 2003
网友评论