Java与模式中关于简单工厂和桥梁模式

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

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

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

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


[img]http://dl.iteye.com/upload/attachment/241519/b0771aac-b31d-3e9d-be17-3dbed3f19ca1.jpg[/img]


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


[img]http://dl.iteye.com/upload/attachment/241521/d4cfdbbc-9c36-34b1-87cc-24c8293bdf15.jpg[/img]


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


[img]http://dl.iteye.com/upload/attachment/241523/30ccb6c1-e1b8-39b9-b248-90ae4dc9bb37.jpg[/img]


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


[img]http://dl.iteye.com/upload/attachment/241524/87241990-d6ba-35dd-9edc-3de2a3926122.jpg[/img]


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

于是，要将上图修改为：


[img]http://dl.iteye.com/upload/attachment/241527/16478cd6-8ef9-370d-b91e-c896e7fb40d2.jpg[/img]


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


[img]http://dl.iteye.com/upload/attachment/241529/7b405f59-8bb9-3af4-af7f-df4f6e084090.jpg[/img]


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

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

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

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


[img]http://dl.iteye.com/upload/attachment/241531/a589b3b4-abe3-3b1e-94ed-a9381fbb2dc6.jpg[/img]


上图表明：
：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例子的图示如下：


[img]http://dl.iteye.com/upload/attachment/241533/0a10d3da-065c-3103-adfb-c767626cfa0b.jpg[/img]


该例的不当之处有以下：

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

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