GETs and SETs
Dom
for the hundredth time, I've written the following:
get { return x; }
set { x = value; }
If that's all that get and set does, isn't it better to just make "x"
a public member?
Vince Panuccio
It all depends on who the code is written for. If its your own
personal thing and making a variable public is easier then go for it.
If your designing a component thats to be used by the wider community
then use properties and methods.
You wouldent want someone setting a variable that you've made public
now would you? Its the perfect control mechanism.
Vince
Dom
> now would you? Its the perfect control mechanism.
>
> Vince
That's what I don't understand. The get and set are both public
anyway, so you are allowing someone to set a variable. Whether you
are using a set, or a public variable, you still end up writing this.
MyObject.X = 10
Vince Panuccio
Not so, if you exclude the SET part then it becomes a readonly
property. A public variable is open to manipulation.
Don't forget you can also drop a whole bunch of code in your get and
set blocks which allow you to maybe set an internal variable before
returning the value also.
Vince
Arnold@arnold.com Mr. Arnold
"Dom" <doliv...@gmail.com> wrote in message
news:1178546294.8...@e51g2000hsg.googlegroups.com...
Oh, you can do more with a public method Get and Set than just get and set,
like make decisions on setting object state, return formatted data, set data
in a formatted manner, call private methods with in an object to validate
data, set or get objects in a collection, etc, etc.
But more importantly, one doesn't want to address a variable in an object
directly with a public setting with anyone being able to instantiate the
object and address a variable, directly.
It must be done through a public method to address the variable.
It's a best OOP's programming practice, that shouldn't be ignored.
sloan
There is a data binding issue also.
I didn't bookmark the article I read, but it made reference that binding to
a property was "correct", but a public variable didn't work the same way.
(Going from memory, but I know I read something because I remember saying
"ahhh, that's a reason beyond just good programming practices")
"Dom" <doliv...@gmail.com> wrote in message
news:1178546294.8...@e51g2000hsg.googlegroups.com...
Andy
A field is implementation, and by exposing it directly you're breaking
encapsulation. The object now has no way to know its state has
changed, and that's a bad thing. Most of my property setters and
getters have more than one line of code.
I would stick with properties, just so you're in the habit of doing
so. If you find you're writing alot of similar code, look at code
gen, or in VS snippets and / or refactoring (Encapsulate Field).
Andy
> There is a data binding issue also.
>
> I didn't bookmark the article I read, but it made reference that binding to
> a property was "correct", but a public variable didn't work the same way.
> (Going from memory, but I know I read something because I remember saying
> "ahhh, that's a reason beyond just good programming practices")
That's a good point as well; IIRC, databinding doesn't acknowledge
fields at all, it will ONLY work with properties.
Larry Smith
It's called "encapsulation". You don't expose member variables to the
outside world. This is a widely documented concept I need not elaborate on
here. Moreover, because properties are a specific language construct unlike
normal accessor functions (dedicated to this purpose), they can be
recognized as such by various tools. For instance, you can create a
"PropertyGrid" control which will automatically read and display all
properties on an arbitrary object (what you see in the forms designer
properties window for instance). An accessor function (or direct exposure to
the member itself) can't be used here because it's just an ordinary function
so there's no way to distinguish between it and an actual property.
sloan
Yep, that was it.
We need a url reference or something.
Geeze, I wish I had kept it.
"Andy" <an...@med-associates.com> wrote in message
news:1178549550.7...@y5g2000hsa.googlegroups.com...
sloan
Ding Ding Ding:
http://www.codinghorror.com/blog/archives/000654.html
Reflection works differently on variables vs. properties, so if you rely on
reflection, it's easier to use all properties.
You can't databind against a variable.
Changing a variable to a property is a breaking change.
There's lot more stuff/debate at the blog.
"sloan" <sl...@ipass.net> wrote in message
news:%23%23nE3kLk...@TK2MSFTNGP03.phx.gbl...
Christof Nordiek
news:1178546294.8...@e51g2000hsg.googlegroups.com...
one reason, for doeing so is, that in OOP one class should be unaware of the
implementation of other classes, for all, if they are from another component
(= assembly in .NET). Fields are implementation, while properties aren't.
(Only the code inside of the set and get is.)
second: For many of your public fields there will come a time, when you want
to change them into properties, because you have to do some validation in
the setter or you want to change the implementation of the storage or ...
This may come sooner as you think, and if it comes later, this even can be
worse. Then, if you simply change the code of your class, all the compiled
client code wouldn't be compatible anymore. Atleast that clients would have
to be recompiled. And for some cases, even that wouldn't be sufficent.
Now, this actually is some how the practicle side of the first reason.
Christof
RedGrittyBrick
> I understand that best practice is to hide fields behind methods, but
> for the hundredth time, I've written the following:
>
> get { return x; }
> set { x = value; }
You shouldn't have to write the above for the hundred and first time:
Don't write getters and setters, generate them instead. I expect your
IDE allows you to generate getters and setters automatically. I'm used
to Eclipse (for Java) which does this for any fields defined in a class.
The SharpDevelop IDE for C# seems to have this feature. I've never used
Visual Studio but I'd be surprised if it didn't have this feature too.
>
> If that's all that get and set does, isn't it better to just make "x"
> a public member?
>
Other people have covered encapsulation.
http://en.wikipedia.org/wiki/Information_hiding#Uses
Bruce Wood
wrote:
> Dom wrote:
> > I understand that best practice is to hide fields behind methods, but
> > for the hundredth time, I've written the following:
>
> > get { return x; }
> > set { x = value; }
>
> You shouldn't have to write the above for the hundred and first time:
> Don't write getters and setters, generate them instead. I expect your
> IDE allows you to generate getters and setters automatically. I'm used
> to Eclipse (for Java) which does this for any fields defined in a class.
> The SharpDevelop IDE for C# seems to have this feature. I've never used
> Visual Studio but I'd be surprised if it didn't have this feature too.
With a caveat: you should be selective about which properties have
setters.
Really, you should start off assuming that all properties are read-
only unless you have a good reason to make them settable. I find that
most properties in most of my classes are read-only. They are set
either through the constructor or as an effect of some method in the
class. I do have a healthy number of settable properties, but I would
estimate it at less than half.
One of the problems with property generators (and with simply using
fields) is that programmers become lazy. They automatically, without
thinking, just generate setters (or use fields) for everything,
whether they're needed or not.
In the end, I find that it's not that much more work to use
properties, even if they're just fronting a field.
Nobody has brought up the subject of classes that are just holding
buckets for data, but even these cases I tend to use properties,
simply because such classes are so rare that it isn't worth breaking
the pattern just for a handful of exceptional cases.