我倾向于有关于“维护整个对象”的策略有所保留，因为通过引用一个对象，该对象传递选定的属性值的快照之间的巨大差异。如果我通过（按价值计算）的属性值的快照，被调用的方法可以做到这一点与有限的数据量没有无意中改变原对象的状态的风险要什么;但如果我传递一个引用到原来的对象，被调用的方法可能会导致各种混乱的。考虑到像与其他开发人员进行实时协作和多个人进行更改过可能长的一段时间的代码帐户的因素，它只是似乎更安全，我要面对的方法只有他们真正需要访问的数据。
“引入参数对象”碰到了时人想一起组参数的数量变大墙。同样的墙实际上是合并了作为一个“功能”战略“与法对象替换法” ，因为它最初阐述：“给新的类构造函数的源对象和每个参数。 ”如果该构造函数将不得不采取更比一些小的数n - 大概在N = 5 ，由于个人口味问题 - 参数，不，那不是我想要做的事。当调用构造函数（或任何方法）的过度赋予参数可以被看作是全面改善应用给定的策略来产生一个必然次优的一部分，它也将涉及交易一“代码味道”的另外，一个可能殷切希望一个更好的选择。 “太多参数”是的，我肯定要解决的一个问题 - 那我愿意接受作为一个长期解决其他问题的一部分而不是一个。
转至：http://www.dfwlt.com/forum.php?mod=viewthread&tid=444
相关链接
Method对象帮手 - 把更多的类方法重构,布布扣,bubuko.com
原文：http://www.cnblogs.com/xszlo/p/3693318.html