Prev: Is it possible to get the program that is launched based on fi
Next: Rounding up to .05
From: Omatase on 28 Jan 2010 22:33
I have a bunch of entity classes with just a whole bunch of properties
in it. I have to count each time one of these properties is read and
written to. I was hoping I could implement a pattern that would allow
me to do that easily so that I didn't have to write custom setters and
getters for each property (I'm using automatic properties for
convenience). Does anyone have any idea how I might be able to do this
easily?

The more I think about it the more it seems unlikely there is any
other solution. My mind keeps veering toward events when I try to
decide how I might easily do this but that's definitely not it. This
post is just hoping there is something I haven't thought of.
From: kndg on 28 Jan 2010 23:00
On 1/29/2010 11:33 AM, Omatase wrote:
> I have a bunch of entity classes with just a whole bunch of properties
> in it. I have to count each time one of these properties is read and
> written to. I was hoping I could implement a pattern that would allow
> me to do that easily so that I didn't have to write custom setters and
> getters for each property (I'm using automatic properties for
> convenience). Does anyone have any idea how I might be able to do this
> easily?
>
> The more I think about it the more it seems unlikely there is any
> other solution. My mind keeps veering toward events when I try to
> decide how I might easily do this but that's definitely not it. This
> post is just hoping there is something I haven't thought of.

I don't think it is possible. So, you would have to write a custom
getter/setter and implement the INotifyPropertyChanged interface. I'm
also interested to know if it really can be done (through reflection or
something), though I don't know whether it could give any value.
From: Peter Duniho on 28 Jan 2010 23:06
Omatase wrote:
> I have a bunch of entity classes with just a whole bunch of properties
> in it. I have to count each time one of these properties is read and
> written to. I was hoping I could implement a pattern that would allow
> me to do that easily so that I didn't have to write custom setters and
> getters for each property (I'm using automatic properties for
> convenience). Does anyone have any idea how I might be able to do this
> easily?

Some possibilities:

� Instead of declaring the classes themselves, use some kind of
code-generation implementation that can auto-generate the classes based
on some template and type description you provide. Then, the inability
to use automatic properties would not be an impediment to your workflow.

� Use Visual Studio code snippets to accomplish something like the above.

� Use reflection to access the properties from a wrapper, keeping a
count in the wrapper

� Instead of properties, use an indexer that takes an enum or string
as the index, mapping the property identifier to a dictionary entry, and
handling the counting in the dictionary.

� Similar to the above, except still have the actual properties, and
implement them using an indexer-like helper class. You can't use
automatic properties in that approach, but at least the implementation
would be trivial.

� Use one of the code-rewriting tools (unfortunately, I don't have
specifics�not something I use personally) to inject your own
access-counting logic into the properties.

� Change the program requirements so that you don't actually need to
know how many times a given property has been read or written.

My preferred solution would be the last one. The number of times a
property's been accessed doesn't seem like a generally useful thing for
a program to need to know.

You mentioned using events as an alternative. I don't see how events
can help reduce the implementation cost, but it could very well be that
there is some value to including events in the overall design. Without
more specifics as to what led you to this design and the context in
which it's going to be used, I can't really say though.

Pete
From: Omatase on 28 Jan 2010 23:26
On Jan 28, 9:06 pm, Peter Duniho <no.peted.s...(a)no.nwlink.spam.com>
wrote:
> Omatase wrote:
> > I have a bunch of entity classes with just a whole bunch of properties
> > in it. I have to count each time one of these properties is read and
> > written to. I was hoping I could implement a pattern that would allow
> > me to do that easily so that I didn't have to write custom setters and
> > getters for each property (I'm using automatic properties for
> > convenience). Does anyone have any idea how I might be able to do this
> > easily?
>
> Some possibilities:
>
>    – Instead of declaring the classes themselves, use some kind of
> code-generation implementation that can auto-generate the classes based
> on some template and type description you provide.  Then, the inability
> to use automatic properties would not be an impediment to your workflow.
>
>    – Use Visual Studio code snippets to accomplish something like the above.
>
>    – Use reflection to access the properties from a wrapper, keeping a
> count in the wrapper
>
>    – Instead of properties, use an indexer that takes an enum or string
> as the index, mapping the property identifier to a dictionary entry, and
> handling the counting in the dictionary.
>
>    – Similar to the above, except still have the actual properties, and
> implement them using an indexer-like helper class.  You can't use
> automatic properties in that approach, but at least the implementation
> would be trivial.
>
>    – Use one of the code-rewriting tools (unfortunately, I don't have
> specifics…not something I use personally) to inject your own
> access-counting logic into the properties.
>
>    – Change the program requirements so that you don't actually need to
> know how many times a given property has been read or written.
>
> My preferred solution would be the last one.  The number of times a
> property's been accessed doesn't seem like a generally useful thing for
> a program to need to know.
>
> You mentioned using events as an alternative.  I don't see how events
> can help reduce the implementation cost, but it could very well be that
> there is some value to including events in the overall design.  Without
> more specifics as to what led you to this design and the context in
> which it's going to be used, I can't really say though.
>
> Pete

I notice you had a suggestion that included a wrapper class. This is
something else that just came to my mind as well. This might be the
way to go. This will let me count the access to those properties
without having to put the functionality in the properties themseleves.

The reason I have such a strange requirement is that I'm making a game
where I will be keeping track of these numbers and persisting them to
a database as a statistic that will be available at some future point
to use in formulae.
From: Peter Duniho on 29 Jan 2010 00:19
Omatase wrote:
> [...]
> The reason I have such a strange requirement is that I'm making a game
> where I will be keeping track of these numbers and persisting them to
> a database as a statistic that will be available at some future point
> to use in formulae.

And what makes that statistic valuable? Is it really worth convoluting
the design of the program just to accommodate that goal? And if the
statistic is so valuable, why isn't it worthwhile to just go ahead and
write a per-property implementation, rather than going after some
harder-to-maintain solution?

It's your program, and I'm not about to try to argue the point. The
above are simply some questions that hopefully give you food for thought
as you head down this path, so that if you do continue to pursue it, you
at least do so with some confidence that it's worth doing.

Personally, I'm skeptical. But if everyone always agreed with me, life
would be pretty boring. :)

Pete
 |  Next  |  Last
Pages: 1 2 3
Prev: Is it possible to get the program that is launched based on fi
Next: Rounding up to .05