这个问题的最佳设计模式是什么?

发布于 2024-12-05 23:33:00 字数 402 浏览 0 评论 0原文

我有一个具有多个属性的类。某些属性可以由其他类更改,但某些属性依赖于其他属性。例如,假设我的类具有三个属性:A、B和C。A和B可以被系统中的其他类更改,并且C等于A + B。该类生成属性更改通知所以我希望当A或B更改时,会为更改的属性(A 或 B)生成通知,也会为 C 生成通知。 我有三个选项(还有其他吗?)

1- 创建一个普通的 C 属性(带有支持字段)并在 A 和 B 的 setter 中添加代码以更改 C。

2- 创建一个普通的 C 属性并监听我的类的属性更改通知在我的班级内部,当 A 或 B 更改时更改 C。

3-为C创建一个计算属性,没有setter,但getter是A+B,在A(和B)的setter中,我触发A(或B)和C的属性更改。

哪一个是更好的设计模式(在C#中) )?我个人比较喜欢2号设计。

I have a class that has several properties. Some properties can be changed by other classes but some properties are dependent on other properties. For example assume that my class has three properties: A, B and C. A and B can be changed by other classes in system and C is equal to A + B. The class generate property change notification So I want when A or B changed, a notification generate for both the changed property (A or B) and a notification is generated for C too.
I have three options (any other?)

1- Create a normal C property (with backing field) and add code in setter of A and B to change C.

2- Create a normal C property and listen to property change notification of my class inside of my class and change C when A or B changes.

3- Create a calculating property for C no setter but getter is A+B, in setter of A (and B), I fire property change for both A (or B) and C.

Which one is a better design pattern (in C#)? I personally like design number 2.

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

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

发布评论

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

评论(4

始于初秋 2024-12-12 23:33:00

听起来观察者模式在这里可能有用。例如,请参见 http://www.oodesign.com/observer-pattern.html。尽管搜索观察者模式会产生许多结果和其他示例,但有些更简单,并且特定于语言。

Sounds like an Observer pattern might be useful here. See for example http://www.oodesign.com/observer-pattern.html. Although a search for Observer pattern will yield many results and other examples, some much simpler, and language specific.

墨洒年华 2024-12-12 23:33:00

我可能会选择 2 和 3 的变体。

您可以为 C 有一个计算属性(仅吸气剂),以便 C = A + B 计算仅在一个地方。

然后,根据您的选项 2,您可以侦听同一类中的属性更改事件...但是,当您检测到 A 和 B 的 PropertyChanged 事件时,无需更新 C,而只需在此时引发 C 的 PropertyChanged 事件时间。

I would probably go with a variation on 2 and 3.

You could have a calculated property (getter only) for C so that the C = A + B calculation is only in one place.

Then, as per your option 2, you could listen to property changed events within the same class... but instead of updating C when you detect a PropertyChanged event for A and B, you only need to raise a PropertyChanged event for C at that time.

荭秂 2024-12-12 23:33:00

2 是最纯粹的,因为它将 A、B 和 C 分开,但它确实涉及属性通知中字符串解析的一些开销。

如果这是一组简单的属性,我会倾向于使用 1,因为它们仍然相当独立,但更新要简单得多。 3 是最糟糕的 IMO,因为 A+B 正在复制无论如何都应该分开的代码(C 通知)。

2 is the purest since it keeps A,B and C separate, but it does involve a bit of overhead qith the string parsing in the property notification.

If it was a simple set of properties I'd be tempted with 1, since they are still reasonably separate but the update is much simpler. 3 is the worst IMO, since A+B are replicating code which should be separate anyway (C notifications).

爱的那么颓废 2024-12-12 23:33:00

这里的问题是,你试图将应该做的事情与微软强迫你做事情的方式混合起来......:)

但除了我的咆哮之外,它认为选项 3 听起来最干净。当然不是 1,这是迄今为止最糟糕的,我认为订阅你自己的属性更改事件可能会导致一些奇怪的问题,当一些可怜的傻瓜将来试图维护代码时,这些问题将很难调试......

如果如果你从高层次上考虑一下,你在 3 中的建议完美地描述了类中发生的事情:

每当属性 A 发生更改时,类的观察者都应该被通知属性 C 也发生了变化(因为它已经发生了变化)。

The problem here is that you are trying to mix the way that things should be done with the way Microsoft forces you to do things... :)

But my rantings aside it think that option 3 sounds cleanest. Certainly not 1, that is the worst by far, and I think that subscribing to your own property change events could lead to some funky problems that would be hard to debug when some poor sap tries to maintain the code in the future...

If you think about it at a high level, what you are suggesting in 3 perfectly describes what is happening in the class:

Any time that property A is changed observers of the class should be notified that property C has also changed (because it has).

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