Re: fields or properties

> For me, I'd much rather have a series of get and sets for each field
that never get used than to take a chance of having a major headache
one day when someone asks me to do something I hadn't planned on.

For the record, so would I.

> Wrong! The problem now is that I've since used that class a grand
total of
> 122 times throughout 10 different modules, all writing to a field
that is
> now private and therefore doesn't exist. So now I have to go
throughout all
> this source code and update it before I can recompile and
redistribute all
> the necessary peices.

With all due respect, as you said: Wrong!

All you have to do is change the name of the (now private) field,
change all references to it within its owning class accordingly, and
name the new property the same as the field was named before. Presto.
You're done.*

Again, I'm not advocating the practice. Just pointing out that it's not
such a big deal in certain work environments.

I never make fields public, or even protected. My fields are always
private. Here's my reasoning for doing this. Programmers, when reading
code, tend to read with assumptions in mind. The more assumptions a
programmer can make about a piece of code, the easier it is to read,
because he/she has to keep less mental structure. For example, (and
this is the good bit) if I can _always_ assume that all fields are
manipulated _only_ within the owning class, then it's easier to
maintain the code. I can relax and think, "I don't have to worry about
this field being changed by any outside software." I can look over that
one class and find _all places_ where that field is changed, and modify
the code accordingly.

If I allow public (or protected) fields, then I have to remember
(constantly) that other classes could (unexpectedly) modify this
field... "behind my back" as it were... and I have to program carefully
to account for that. Yuck. It breaks encapsulation and makes code
difficult to maintain. Sometimes trivially so, sometimes awfully so.
However, I'm a lazy programmer and I don't like cluttering my brain
with unnecessary detail.

Yes, it's more work typing those extra properties, but then it makes it
easier on me later... and I end up reading code 100 times more often
than I write it. :)

* There is one exception that I think does point out why one should
always use properties rather than public fields. You can do this with a
property:

MyMethod(6, null, ref myObject.MyField);

Change "MyField" to a property and kaboom! You can't pass properties by
reference or as "out" parameters.

However, that's the only case in which you would have to modify client
code. For my part, that's just another good reason to always use
properties.

.

Relevant Pages

  • Re: Getting and Setting and best practise
    ... to interpret which private variable you wanted. ... C - you make seperate getter/setter functions for each private ... if I've been a good little programmer ... interface to the object INSIDE of the object. ...
    (comp.lang.php)
  • Re: A question (confusion) about closure
    ... Local variables have dynamic duration and local accessibility. ... Own/static variables have indefinite duration and local (private) accessibility. ... Closures are just like own/static variables, ... system and each programmer sets up his/her own private sub-domains ...
    (comp.lang.lisp)
  • selective access to different classes
    ... I have asked the question in java programmer newsgroup, ... operate in turns call each operaion in sequence, passing only those ... parameters which they modify. ... If any other common design pattern exists for this kind of selective ...
    (comp.object)
  • Re: Why less emphasis on private data?
    ... no concept of private data in C either, ... One does not need in C the static keyword to make a variable defined inside a function i.e. a so called 'automatic variable' private to that test. ... To Neil Cerutti: If a programmer in C has got a pointer to some piece of memory, that piece is at the mercy of the programmer. ...
    (comp.lang.python)
  • Re: strange compiler message
    ... > even if the programmer were sloppy enough not to check the function signature, ... constructed and bound to a reference to non-const string. ... >>to modify the original object. ... > void foo(const int i) { ...
    (comp.lang.cpp)