prototype模式随想

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

class client

{

      //赋值操作

}

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

class Factory

{

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

}

class client

{

     Factory.Create(Class o);

}

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

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

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

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

原文地址:https://www.cnblogs.com/bmrxntfj/p/1258060.html