prototype模式随想

有时业务中客户不希望再次输入以前输过的数据。而通过new一个实例，然后用以前的数据一一赋值，显得有些麻烦。

class client

{

      //赋值操作

}

这些代码留在客户代码中会模糊了客户的职责，然而尽管可以使用Factory Method来解决。

class Factory

{

     public Class Create(Class o){//赋值操作;}

}

class client

{

     Factory.Create(Class o);

}

但是如果这些数据形成了一个类层次结构，不同的子类需要不同的赋值方式，就会需要不同子类的工厂，导致类的数量增多。尽管还有其他方面的原因，然而有些是跟语言支持有关。

 

在以前做过的一个项目中，客户希望用以前填过的单子，修改几处就可以，很容易就想到了prototype模式。但因为prototype模式而饱受困扰，到最后通过日志记录单子的整个处理过程才发现：

实现Clone操作需要考虑业务中每个数据怎么处理，也就是deep clone.处理不好，到后面出问题，还以为是中间什么地方出错了。

成功的经验值得总结，然而失败的经验更值得总结。