蒙乔森做出一个绝对承诺:相同的种子,相同的数据,永远如此,在任何机器上皆然。一个人物形象是“一次性生成”的,这引出了一个问题,听起来像是实现细节,但实际上是契约的一部分:一旦在随机流中的哪个位置?如果搞错了这一点,一次无害的代码更改就会悄然改变所有
升级用户的体验。
将操作的随机性想象成一卷按顺序消耗的抽取带,d0, d1, d2, ...。人物形象包消耗其中固定的一块(性别,然后是匹配的名字,接着是姓氏),而任何独立的成员,例如年龄,则自行抽取。分叉点在于人物形象包的那一块落在何处。
public sealed class 客户
{
public string 名字 { get; set; } // 人物形象特征
public int 年龄 { get; set; } // 独立字段
public string 姓氏 { get; set; } // 人物形象特征
public string 电子邮件 { get; set; } // 人物形象特征(源自姓名)
}
两种选项,具体化
两者同样合理。区别在于模型变更时的稳定性。
看看当年龄移动到类型顶部时会发生什么。
A,在构造时急切执行:在任何成员之前,将人物形象包作为固定块抽取。
包[d0,d1,d2] -> 年龄=d3,名字/姓氏/电子邮件读取缓存的特征
将年龄移到顶部?包仍然是第一个,人物成员不消耗任何东西,
因此没有任何变化。年龄保持为 34,姓名保持为玛丽亚·加西亚。
B,在第一个人物成员处延迟执行:在该成员的位置抽取人物形象包。
年龄=d0 -> 名字触发包[d1,d2,d3]
将年龄移到顶部,整个抽取带滑动:年龄抽取 d0 而不是 d3,
包发生偏移,每个值都发生变化。
选择
在构造时急切执行。决定性属性是稳定性。在急切模式下,人物形象在成员填充之前作为一个块进行抽取,绑定的成员对流不可见,因此重新排序字段或添加新特征不会移动你已有的值。这对于种子/演示任务最为重要,因为人们会不断编辑他们的模型。急切模式也符合整个库的急切构建哲学:实体与对象在同一时刻被抽取,这是一个黄金测试可以固定的单一点。
它付出了一点微小但定义明确的代价:人物成员不再按照它们在成员顺序中的各自位置进行抽取,这是有意偏离库其余部分遵循的每成员规则。我认为,为了在人们经常编辑的字段上实现重排不变性,这是一个公平的代价。
免责声明:本文内容来自互联网,该文观点不代表本站观点。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请到页面底部单击反馈,一经查实,本站将立刻删除。