设计模式之abstract factory篇(3)

 

   所谓 Factory ，就是能生产出具体对象的 " 模块 "( 接口 ) ，谓之工厂。所谓 Abstract ，就是本身并不做代码的具体实现，用接口来和用户沟通。 Abstract Factory ，对用户隐藏具体的实现细节，但是能为用户提供出所需要的对象，能提供的对象的方法已经被接口所定死。
    想象 Abstract Factory 是一个生产智能玩具的工厂，所有生产出的玩具（小机器人）都具有 2 个功能（强调：并只有 2 个功能）：攻击，移动，已知该工厂可以生产的玩具有赛亚人孙悟空、 CS 警， CS 匪。我是用户，使用这家工厂的时候，我只需要告诉他我需要哪种玩具，得到后就可以对该玩具发号施令，移动或者是攻击。孙悟空用跟头云移动， CS 的两个小兄弟只能靠走，孙悟空的攻击是发冲击波， CS 的玩具只能是跑了，但我不管这些具体细节，他们只要能听我的命令攻击或者是移动就可以了。好了，这就是 Abstract Factory 能做什么，并且怎么用，看起来不错。
    看看 Abstract Factory 的优点：
        1. 隐藏了对象的具体实现。我不管你怎么生产孙悟空和 CS 小人的，虽然他们内部构造可能千差万别。
        2. 更换对象只需要一次操作。我只需要告诉一次工厂，我要孙悟空或者 CS 小人。
        3. 对对象操作的接口一致。我只需要知道工厂宣称的他的玩具支持的命令，学习一次就能操作这个工厂所有生产出的玩具了，以后他们能生产会喷火的霸王龙的时候我曾经发布的这些命令它也可以理解。
        4. 对对象的访问一致性。要么是对孙悟空下达命令，要么是对 CS 小人下达命令。
    似乎一切工作的都很好，可突然有天我知道孙悟空应该变成超级赛亚人更厉害。用户需求变更了，工厂也需要改啊，给所有玩具添加了一个命令：变身。工厂的变化只能给所有对象都变化，问题来了，孙悟空能变身， CS 小人怎么变身啊，委曲求全吧， CS 小人接收到这个命令不做相应。
    从满足需求变更这点上来看，功能似乎已经实现。但是每次需求变更（接口变更）时候，都需要对工厂里现有的所有实现做更改，有点不爽。
    现在也看出点 Abstract Factory 的缺点了：
        1. 接口发生变化时候，所有实现类都需要做改动。
        2. 接口发生变化时候，可能导致相关的客户端都需要重新改动，如果接口调用顺序又相互关联的话，那问题就更多了。