CODEWITHSUNDEEP
propertiesinotifypropertychanged
mans
mans

Reputation: 18228

what is the best design pattern for this problem?

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.

Upvotes: 0

Views: 219

Answers (4)

Matthew
Matthew

Reputation: 13332

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).

Upvotes: 0

GazTheDestroyer
GazTheDestroyer

Reputation: 21261

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).

Upvotes: 0

Phill_P
Phill_P

Reputation: 399

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.

Upvotes: 0

mikey
mikey

Reputation: 2072

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.

Upvotes: 1

Related Questions