Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Auto-implemented getters and setters vs. public fields

I see a lot of example code for C# classes that does this:

public class Point {     public int x { get; set; }     public int y { get; set; } } 

Or, in older code, the same with an explicit private backing value and without the new auto-implemented properties:

public class Point {     private int _x;     private int _y;      public int x {         get { return _x; }         set { _x = value; }     }      public int y {         get { return _y; }         set { _y = value; }     } } 

My question is why. Is there any functional difference between doing the above and just making these members public fields, like below?

public class Point {     public int x;     public int y; } 

To be clear, I understand the value of getters and setters when you need to do some translation of the underlying data. But in cases where you're just passing the values through, it seems needlessly verbose.

like image 720
tclem Avatar asked Sep 21 '08 17:09

tclem


People also ask

Should getters and setters be public or private?

Usually you want setters/getters to be public, because that's what they are for: giving access to data, you don't want to give others direct access to because you don't want them to mess with your implementation dependent details - that's what encapsulation is about.

Why are getters and setters better than public?

Getters and setters are poor design as well. They are better than public variables because they allow the class to enforce invariants.

Why is it useful to have getter and setter methods rather than public attributes in a class?

Getters and setters are used to protect your data, particularly when creating classes. For each instance variable, a getter method returns its value while a setter method sets or updates its value.

Why getters and setters are not public variables?

getters and setter can have validation in them, fields can't. using getter you can get subclass of wanted class. getters and setters are polymorphic, fields aren't. debugging can be much simpler, because breakpoint can be placed inside one method not near many references of that given field.


2 Answers

I tend to agree (that it seems needlessly verbose), although this has been an issue our team hasn't yet resolved and so our coding standards still insist on verbose properties for all classes.

Jeff Atwood dealt with this a few years ago. The most important point he retrospectively noted is that changing from a field to a property is a breaking change in your code; anything that consumes it must be recompiled to work with the new class interface, so if anything outside of your control is consuming your class you might have problems.

like image 178
Dexter Avatar answered Oct 13 '22 21:10

Dexter


It's also much simpler to change it to this later:

public int x { get; private set; } 
like image 30
Brad Wilson Avatar answered Oct 13 '22 19:10

Brad Wilson