设计模式笔记(3 PROTOTYPE & SINGLETON)

PROTOTYPE(原型)
适用性:
当一个系统应该独立于他的产品创建,构成和表示时,要使用该模式.

思考:
对比FACTORY METHOD,工厂方法需要统一的Creator,而Creator的提供和被创建对象之间是各自独立的.也就是说,必须为具体的产品类提供相应的Creator(当然,C++的模版技术可以简化一些工作).从语意上来看,工厂方法是凭空创建一个对象,而原型是从已知实例复制新的拷贝.效果上,相当于把Creator的责任推给了具体的产品类,也就是产品类提供的Clone方法.假设,我们改变Clone这个名称为Create,那么,Create其实就是工厂模式需要的Creator,只不过这个Creator只有从已有的产品实例上才能调用.剩下的问题就是需要上帝的一脚----我们需要在某个地方提供所有产品类的第一个实例.
继续看工厂方法的Creator,假设,我们设计一种Creator对象,它的构造过程就是绑定到一个产品实例,创建实现就是调用绑定产品的Clone方法.那么...那么...原型可以作为工厂方法中Creator的实现技术!

有些产品可以创建,但是复制却很困难.典型的情况是产品内拥有某种资源(句柄,端口等等),循环引用也是一大障碍.在复制的时候,深复制还是潜复制?这也是一个破费思量的问题.在C++环境中,复制一个值语意的类是相对容易的.非数值类的复制语意是不太明确的,这时候可能就并不适合使用原型模式.

SINGLETON(单件)
适用性:
1.一个类只能有一个实例,且可从一个众所周知位置访问它时.
2.当这个唯一实例应该是通过子类化可扩展的.

思考:
一个类只能有一个实例的情况似乎是很少的,通常的约束是所有客户都必须访问同一个实例.此时,单件仅仅起到了避免全局变量的作用,这种单件的使用实际上是不良的.和全局变量相比,它没有解决广泛耦合的问题,只是减少了名字冲突,这种情形的大量发生,很可能意味着大量的复杂耦合.我的经验是,对于动态信息的管理,不要使用单件,常见的错误使用方法是把环境管理类,连接管理类实现为单件.这样做将失去扩展性,假设需要支持多会话,那么实现多个会话环境就会遇到麻烦,要想每个会话都有自己的连接管理也将是非常困难的.
单件适合用在一些和静态信息关联的地方,例如参数化类厂实现,类实现是静态的,用单件对静态信息加以管理,是非常适合的.
Loki提供了单件模式的一个实现.