Check if an variable in an object has changed

Question

2.33/5 (3 votes)

See more:

Hello folks,

I want to detect if variables in an object has changed. Like an method that outputs an boolean array, so one boolean for each field, that determins if the field has changed in the last update.

I don't want to use properties, as my class has 90 fields. So to write an property for each field would be a pain.

My first approche was to copy the last state of the object and compare it with the updated one. But the process of copying and comparing would be also complicated, as I don't want to use a duck copy method to copy it (for the same reason I don't want to use properties) and also the comparing isn't really practically as I would have to override the equals method for all classes I used in my object.

My second approche was to serialise my object, update it and than serialise it again and compare the two byte streams i got. But I don't like this either as I would have to serealize it twice per update, so it would consume my resources really fast.

What do you think I could do to solve this problem effectively?

Posted 16-Jul-13 7:40am

IDominator

Add a Solution

Comments

Zoltán Zörgő 16-Jul-13 14:00pm

Are those 90 fields of the same type? Do they have any name, or you want to access them by an index? In the later case you can use a single indexed property.

Maciej Los 16-Jul-13 14:06pm

No, it's not must be a painful. Have you heard about raising events?

Sergey Alexandrovich Kryukov 16-Jul-13 21:02pm

What do you call a "variable in an object"?
Why not using properties? Having 90 or even much more field is not a valid excuse at all.
—SA

4 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CHill60 · Answer 1 · 2013-07-16T07:57:00

Solution 1

"So to write an property for each field would be a pain" ... then write a program snippet to generate the code for you!

e.g. by using Reflection (http://msdn.microsoft.com/en-us/library/ms173183(v=vs.80).aspx[^])

You could also check out this codeproject article State Pattern in C#[^]

Posted 16-Jul-13 7:57am

CHill60

Comments

Sergey Alexandrovich Kryukov 16-Jul-13 21:09pm

Well, you and me can easily devise the appropriate techniques, but I don't think that OP (who is naive enough to think that 90 members is a hassle in using properties) could. The problems involving reflection is not so trivial. Besides, the performance issues (which we cannot discuss here as we don't know what OP is going to do with those members) may lead to requirement to use Reflection with System.Reflection.Emit, which is way more difficult.

So, I don't know what to say, so I did not vote this time. There is a rational grain in your post but 1) it really depends, 2) it needs at least some elaboration.

Also, I think the problem is really much simpler, in many thinkable cases, anyway. I just can see that "I don't want to use properties, as my class has 90 fields" is an absolute bogus. Using properties is a real key. Please see my answer.

—SA

Sergey Alexandrovich Kryukov · Answer 2 · 2013-07-16T15:05:00

Solution 2

The key here is really to use properties. Having 90 data members is just nothing, not a valid reason not to use properties. Besides, you can hide many data field under a single property. Just do it.

—SA

Posted 16-Jul-13 15:05pm

Sergey Alexandrovich Kryukov

IDominator · Answer 3 · 2013-07-17T02:07:00

Solution 3

I have solved it. I wrote a source code generator, which generated me for all fields a property. Inside the property it sets a defined boolean inside a boolean array, if the field has been changed. The only problem i have are the Dictionaries and Lists, as they can only be accessed by the getter, not the setter.

Posted 17-Jul-13 2:07am

IDominator

Comments

johannesnestler 17-Jul-13 8:56am

consider implementing INotifyPropertyChanged Interface instead of your "own", this can have many benefits later on - even if you decide not to use it now - it's a good thing to know. Btw. If you do things in the "common" way, your code will be easier to read by others (but maybe you don't want that ;-)) What do you mean accessed by the getter? It's quite normal to not have a pulbic setter for collections, so the can't be set to null and to enable Features like lazy loading...

johannesnestler 17-Jul-13 8:59am

Ah I forgot to mention: If you created a "Generator" maybe you also want to look into text transformations (http://msdn.microsoft.com/en-us/library/vstudio/bb126445.aspx) - useful if you want to integrate the code generator in your build process.

IDominator 17-Jul-13 17:36pm

I mean with getter that for example if you add to a list a value, but this list is a property, this add "command" will pass only through the get code not the set code. And that is the problem with the code. I cant set my boolean in the get code, as it would detect a change if I only read what's inside the list.
I also don't want to use handlers, as this class would be used often (this class is part of a dictionary) so it could be that I get an overflow as i have too many handlers.

johannesnestler 18-Jul-13 9:33am

Hi again, Sorry I overlooked that comment (you didn't use the reply button, so I wasn't informed). There is also a solution for detecting changes in an collection - have a look at ObservableCollection (http://msdn.microsoft.com/en-us/library/ms668604.aspx)

johannesnestler · Answer 4 · 2013-07-17T02:39:00

Solution 4

I'm wondering no one mentioned INotifyPropertyChanged Interface (http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged(v=vs.95).aspx[^]

normally the prefered way for me to create an observable object. For your case I can imagine to have a central handler for all PropertyChanged events from your object updating your "boolean Array" of "dirty/changed" states. Or just react to changes imediately.

And if you want your object visualized you can use twoway bindings (e.g. WPF) out of the box.

Edit: I fully agree with SA and others about 90 members is no excuse for not using properties (even private ones). If your object exposes 90 public variables - something with your design is maybe wrong. consider grouping related data to new (container-)classes or break your "big" class into smaller ones. And: make using properties a habit you never question - I think this is common sense in the whole .NET community. The benefits by far outweight the typing work (but there are snippets, code Generators, tt,....).

greetings

Johannes

Posted 17-Jul-13 2:39am

johannesnestler

Updated 17-Jul-13 2:44am

v2

Comments

IDominator 18-Jul-13 6:05am

Thank you for your support Johannes.
The Problem with INotifyPropertyCahanged is that I have to declare a event handler for each object of my class. And I will have more than 1000 objects with this handler. I don't know how much it will burn up my resources...

johannesnestler 18-Jul-13 7:19am

Hi IDominator,

I think you missunderstood how to implement INotifyPropertyChanged - you have one event for all properties and therefore can use just one handler for all property changes. This involves the performance impact of raising an event (if no handler is attached you wont even have that). I think compared to possible problems you may have with code generation (regenerating?) and additionally writing to an array on every change (you didn't mention what you want to do with the detected changes), which involves also a (little) performance loss, INotifyPropertyChanged would be the way to go for me (+ all additional benefits I mentioned, not least that every other .NET programmer (should) understand this pattern) - In my last project I bound a lot of big objects to a WPF-View all implementing INotifyPropertyChanged and INotifyPropertyChanging + used a lot of ObservableCollection<xxx> - no performance problems if memory is no concern. (Most MVVM frameworks depend on or use it heavily too)

IDominator 18-Jul-13 9:14am

ok I'll try it

johannesnestler 18-Jul-13 9:26am

good to hear - If you have any problems feel free to ask me - I think I have some experience with this topic... But all in all it's not that hard. Just follow the MSDN aricle or if you use latest .NET Versions, have a look at answer 58 at http://stackoverflow.com/questions/1315621/implementing-inotifypropertychanged-does-a-better-way-exist or use one of the other tips to shortcut the typing work. Btw. it seems you didn't know about Snippets in VisualStudio (I assume that because you feared the typing work for properties in your question). Have you tried them (prop, propd, etc.). I love them and created many of them for my use(very easy to do - just follow the examples) and I have one which gives my perfectly formated, commented, notifying properties in my format and coding style...