fields or properties

  • Thread starter Thread starter julien
  • Start date Start date
Now please tell me what value there is of spending time on turning a public
field into a property that does nothing. All I see is time spent and
mis-communication.
Click to expand...

Miscommunication? What exactly is being miscommunicated? There's only
miscommunication if you draw an inference that a property *must* be
doing some validation or the like. That's an inference which I haven't
heard anyone else draw before.

As for spending time making properties, I refer you to your own earlier
post:

<quote>
VS2005 and especially Eclipse have excellent support for turning a
field into a property (get./set- method), and a property into a method.
</quote>

So it needn't take long at all - just highlight the field and turn it
into a property. As you may know, Eclipse will even take your preferred
prefix into account, turning m_someValue into getSomeValue() and
setSomeValue() if you like using m_ for example.

Then when you're in the middle of a debug session and want to know when
someone is accessing something, for instance, you don't have to wish
that you'd turned it into a property earlier - and the same goes for
when something which wasn't really public as such but got used a bit
more widely than you originally intended needs to change...
 
Now please tell me what value there is of spending time on turning a
public
field into a property that does nothing.
Click to expand...

The bottom line for me is maintenance and reading code for
understanding. Very often I find myself debugging code, thinking, "Oh,
heck. I forgot that such-and-so quantity stored in my class can't be
negative." I just pop down to the property setter and put in a check,
and I've now guaranteed that that field can never be negative.

With public fields I have to constantly keep in mind that _anyone_,
_anywhere_, can set those fields to whatever they like. Public string
field? Better have checks for null every time you use it, because some
other class could set it to null. As a matter of fact, that goes for
any public reference field.

Religiously encapsulating everything just makes for easier-to-maintain
code, which means cheaper-to-maintain code.
 
With all due respect, as you said: Wrong!

Sorry, you are correct... :-)

I think we're on the same page though... I was in the middle of trying to
convert a finger print module over to C# when I wrote that and only had half
my brain thinking of what I was typing. You are absolutely correct...

glenn
 
Michael,

First of all the answer to a previous question: yes, I do and have
programmed on applications that have been running for over 10 years. One
particular is a business system that has experienced all sorts of problems
that were not thought out well in the beginning that we had to go back and
redesign later. Fact of life is, no one is perfect. We all make mistakes
and we have to fix the ones we make.

It sounds like you program on a lot of various projects and have lots of
time constraints and as such I can agree with your position somewhat.
However, editors abilities to search and replace and refactor do not take
care of millions of lines of code and 30 different modules that make up a
system. Can things be fixed? Well of course, everything can be fixed. If
you are only writting a piece and you'll be gone and on to the next
customer, then perhaps you don't care about 2 years down the road and I
understand that I guess. However, I have to be here for the long hall and
have been here for the long hall, and as such I try to design and write code
that will require as little necessary change as possible when that absolute
100% sure this will work attitude turns to Oh shit, I didn't think about
that one.

Neither of us are wrong with our opinions, we just don't quite share the
same opinions... :-)

glenn
 
Bruce Wood said:
The bottom line for me is maintenance and reading code for
understanding. Very often I find myself debugging code, thinking, "Oh,
heck. I forgot that such-and-so quantity stored in my class can't be
negative
Click to expand...

The bottom line for me is maintenance and reading code for
understanding. Very often I find myself debugging code, thinking, "Oh,
heck. I've been doing pageup and pagedown for a property that does nothing
but get and set."

I still don't get the value of hiding fields in properties that does
nothing. All I see is a waste of time and codebloat.

For readibility, I sure could do without the bloat.

- Michael S
 
Michael S said:
The bottom line for me is maintenance and reading code for
understanding. Very often I find myself debugging code, thinking, "Oh,
heck. I've been doing pageup and pagedown for a property that does nothing
but get and set."
Click to expand...

Whereas I can't remember the last time I did that. If I really care
what a property is doing during debugging, I can step into it.
Otherwise I'll just assume it does "the right thing".

(Mind you, I don't tend to spend much time in the debugger.)
I still don't get the value of hiding fields in properties that does
nothing. All I see is a waste of time and codebloat.

For readibility, I sure could do without the bloat.
Click to expand...

It's very easy to put all your properties in a region so you don't need
to see them unless you really want to.
 
Back
Top