Java与模式中关于简单工厂和桥梁模式的讨论及改进意见

作者：胡拥军   hu.yong.jun@ctgpc.com.cn


    近日仔细看了“Java与模式”一书，收获不小。

    提出几点改进意见，也是对其中模式的讨论。

    一、该书中“简单工厂”的提出没有必要，且给人以误导。

    该书定义简单工厂表明：工厂直接创建具体产品，图示如下：

    但简单工厂模式引用的DateFormat例子却不符合简单工厂模式。书中的例子图示如下：

    图中明确指明DateFormat创建的对象的类型是自己，因此该图应为：

    在该节的总结中，又给出图示：

    
    并总结：“与一般的简单工厂模式不同的地方在于，这里的工厂角色与抽象产品角色合并成一个
类。换言之，抽象产品角色负责具体产品角色的创建”。这个结论是错误的：
    ：单单从简单工厂涉及到的技术（未使用反射等特性），父类不可能返回具体子类对象，它根本
就不知道子类类型。
    ：根据简单工厂定义，简单工厂直接创建具体产品，因此简单工厂角色无法与抽象产品角色合并
为一体。

    于是，要将上图修改为：

    简单工厂模式的定义图也要修改为：

    这样，该图是工厂方法的定义。综上，简单工厂模式的引入是没有必要的。该书称，引入简单工
厂的目的原本是为了浅显明白地介绍第一个模式，反而因为错误而误导读者，此处有欠考虑。

    二、桥梁模式引入Peer结构例子，不能正确地说明桥梁模式的本质和意图，极大地误导读者。

    桥梁模式的意图就是将逻辑功能与其物理实现分开，它的本质就是逻辑功能和物理实现互相独立
地变化，同时逻辑功能必然与物理实现有关系（逻辑功能由物理实现体现）。
    逻辑功能是与应用相关的，它与底层物理结构没有很强的关系；物理实现是与底层物理结构关联
的。因此可以说逻辑功能是属于应用层的，而物理实现是属于物理驱动层的。

    用一个图示可以说明，如下（当然，此处的Peer应是Impl才好）：

    上图表明：
    ：Button在应用中有3种类型：X type，Y type，Z type。这实际上是Button的产品系列。也可以
说，Button按逻辑功能划分为X，Y，Z等3种。
    ：Button实现有2种：UNIX，Windows。这实际上是Button实现的产品系列。也可以说，Button按
实现方式可以分为UNIX和Windows两种。
    ：Button只知道ButtonPeer，而不知道有UNIXButtonPeer和WindowsButtonPeer。如：XtypeButton
并不知道UNIXButtonPeer。
    上图说明，2个类层次表示“产品系列”的概念，且是“正交”的2个产品系列，而非“相似”的产
品系列。
    
    然而，该书引入Peer例子的图示如下：

    该例的不当之处有以下：

    1、该例不能说明物理实现的变化。Toolkit只会给出一个实现，即当前操作系统特定的实现（XxxPeer）。
    2、同理，该例不能说明逻辑功能的变化。
    3、2个类层次结构实际上是表示“产品簇”，而非“产品系列”。
    4、Button知道ButtonPeer，Label也知道LabelPeer，等等。根据桥梁模式定义，Abstraction类层
次只应知道抽象的Implementor，而不应当知道具体的ConcreteImplementor。

    GoF的书中也是用Peer结构的例子来说明桥梁模式，但GoF只是说明了桥梁模式的一个特殊，并没有
用例子归纳出桥梁模式的普遍形式。该书的桥梁模式中，AirPlane的例子非常好，说明了桥梁模式的普
遍意义。

    建议作者二版加以改进。