当实例用于“假设”情况时,不可变类适用。工具?

发布于 2024-10-23 17:21:19 字数 347 浏览 7 评论 0原文

我有一个类,它基本上表示模型的参数,并封装使用这些参数计算模型值的逻辑。我正在尝试决定这个类是否应该是不可变的。在实践中,模型的实例将通过拟合某些数据集来生成,因此从这个意义上说,该实例是不可变的(至少对我来说)是有意义的,因为它与外部数据相关。

另一方面,将有一个 GUI 让用户进行“假设分析”,其中他们可以更改参数以查看它如何更改模型值。因此,我可以使模型可变以简化此操作,或者在每次更改参数时创建新副本。后者看起来很尴尬,特别是如果有例如 5 个参数可以单独上下勾选...似乎我必须为每个返回副本的参数实现一个 SetX() 方法,对吗?

我是否想得太多了,或者这里有合适的模式可以使用吗? (这是 C# 代码,尽管我猜并不是特定于语言的)

I have a class that basically represents the parameters of a model, and encapsulates the logic to calculate values of the model with those parameters. I'm trying to decide if this class should be immutable. In practice, instances of the model will be generated by fitting to some data set, so in that sense it makes sense (to me at least) for that instance to be immutable since it's tied to external data.

On the other hand, there will be a GUI to let a user do a "what-if" wherein they can change the parameters to see how it changes model values. So I could make the model mutable to make this easy, or create new copies every time a parameter is changed. The latter seems awkward, especially if there are e.g. 5 parameters that could be ticked up and down individually...seems like I would have to implement a SetX() method for each parameter which returns a copy, right?

Am I overthinking this, or is there a proper pattern to use here? (This is C# code, though I guess not really language-specific)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

∞琼窗梦回ˉ 2024-10-30 17:21:19

仔细考虑该对象将如何实际用于您的推测分析。对于简单的、一次性的、让我们改变字段尝试一些东西然后将其更改回来的场景,当然,只需使其可变即可。但假设你想拿出大枪;那么拥有一个不可变的模型就变得更好了。

Data d = whatever;
// What if we mutate X and Y? Which one maximizes the value of Foo(d) ?
var query = from x in Range(0, 100)
            from y in Range(0, 100)
            let mutated = data.MutateX(x).MutateY(y)
            orderby Foo(mutated)
            select mutated;

var max = query.First();

等等。使用不可变模式,编写推测性查询变得更加容易,跨多个核心并行化这些查询变得更加容易,等等。

Consider carefully how the object is going to actually be used for your speculative analysis. For straightforward, one-off, let's-mutate-the-field-try-something-and-change-it-back scenarios, sure, just make it mutable. But suppose you want to pull out the big guns; then it becomes much nicer to have an immutable model.

Data d = whatever;
// What if we mutate X and Y? Which one maximizes the value of Foo(d) ?
var query = from x in Range(0, 100)
            from y in Range(0, 100)
            let mutated = data.MutateX(x).MutateY(y)
            orderby Foo(mutated)
            select mutated;

var max = query.First();

And so on. With an immutable pattern it becomes much easier to write speculative queries, it becomes much easier to parallelize those queries across multiple cores, and so on.

随心而道 2024-10-30 17:21:19

后者看起来很尴尬

,这就是你的答案。 API设计的目标是让编写代码尽可能简单。如果某个特定模式比替代方案更困难或更尴尬,则替代方案可能是正确的。

The latter seems awkward

Well that's your answer. The goal of API design is to make writing code as easy as possible. If a particular pattern makes it more difficult or awkward than the alternative, the alternative is probably correct.

温柔女人霸气范 2024-10-30 17:21:19

我想你可能有点想太多了。虽然可能有一个非常优雅的设计模式,使用八个类和四个接口,但我认为最简单的方法是使其成为一个普通的可变类。考虑一下您的意图:您想要一个可以从外部数据加载的模型(可能是返回模型实例的静态方法),并且参数可以根据用户输入进行更改。这似乎是您日常普通班级的一个用例。

您还可以选择将类分成数据类和策略类,第二个类包含可更改的参数并使用策略模式之类的东西来计算结果。

I think you're probably overthinking this a little bit. While there is probably a very elegant design pattern for this that uses eight classes and four interfaces, I think the simplest route forward would be to make it a normal, mutable class. Think about your intention: you want a Model that can be loaded from external data (perhaps a static method returning a Model instance) with parameters that can change according to user input. This seems like a use case for your everyday, garden variety Class.

You may also choose to separate your classes into a Data class and Strategy class, the second which contains the changeable parameters and uses something like a Strategy pattern to calculate the results.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文