我有一个有几个属性的类。一些属性可以被其他类改变，但是一些属性依赖于其他属性。例如，假设我的类有三个属性：A，B和C.A和B可以由系统中的其他类更改，C等于A + B.该类生成属性更改通知所以，当A或B发生更改时，会为已更改的属性（A或B）生成通知，并会为C生成通知。 我有三个选项（任何其它？）这个问题的最佳设计模式是什么？
1-创建一个普通的C属性（带背衬场）和在A的设定器和B添加代码以改变C.
2-创建一个普通的C属性并收听我班内属于我班的财产变更通知，并在A或B变更时更改C.
3-对C创建一个计算属性没有setter但是吸气剂是A + B，在A（和B）的设定器，我火两者的性质变化（或B）和C
哪一个是一个更好的设计模式（在C＃中）？我个人喜欢设计编号2.
听起来像一个观察者模式可能在这里很有用。例如参见http://www.oodesign.com/observer-pattern.html。虽然搜索Observer模式将产生许多结果和其他示例，但更简单一些，也是特定语言。
我可能会用变化去2和3
你可以有一个计算的属性（只吸气剂），对C，使C = A + B的计算是只在一个地方。
然后，根据您的选项2，您可以侦听同一类中的属性更改事件......但是当您检测到A和B的PropertyChanged事件时，您只需要引发PropertyChanged事件为C当时。
你提到你想在一个地方进行C计算的事实是一个很好的观点。我认为我们可以通过编写代码来单独实现这一点，C = A + B采用单独的方法，并在检测到A或B发生变化时调用。 – mans
是的，这是真的，我没有太多的选择。 2的风险非常小，如果某些代码在不通过属性设置器的情况下更改A或B的后备字段，则C可能不同步，而计算出的属性不能同步。有了这样一个简单的例子，虽然这可能是一个非常低的风险。 –
这里的问题是，你正在试图混合的方式，事情应该与微软的方式逼你做的事情要做...... :)
但我咆哮抛开它认为选项3听起来干净。当然不是1，这是迄今为止最糟糕的，我认为订阅自己的财产变更事件可能会导致一些时髦的问题，当一些可怜的SAP尝试在未来维护代码时将难以调试......
如果您在较高的水平想一想，你所提出的建议在3恰如其分地描述了什么是在类发生的事情：
该性质的改变之类的观察员应通知该财产C有任何时间也改变了（因为它）。
2是最纯粹的，因为它使A，B和C保持分离，但它确实涉及属性通知中字符串解析时的一些开销。
如果这是一个简单的属性集，我会受到1的诱惑，因为它们仍然是合理分开的，但更新更简单。 3是最差的国际海事组织，因为A + B正在复制代码，无论如何都应该分开（C通知）。
观察者模式是好的，在这种情况下，观察者和Observable是同一个类。使用这种模式等于设计2，当类听自己的财产变化通知，并因此观察自己的变化。 – mans