近日仔细看了“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的例子非常好,说明了桥梁模式的普
遍意义。
提出几点改进意见,也是对其中模式的讨论。
一、该书中“简单工厂”的提出没有必要,且给人以误导。
该书定义简单工厂表明:工厂直接创建具体产品,图示如下:
[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的例子非常好,说明了桥梁模式的普
遍意义。