[Natman]

I've been making my own game in XNA, borrowing code from Kurt Jaeger's XNA 4.0 Game Development by Example. I notice he uses a lot of public fields instead of private ones with properties. Some of the fields he declares as public, I don't quite understand why he does. For instance, inside his Sprite class from Robot Rampage:

public Texture2D Texture;

However I don't think the Texture is ever accessed from outside the sprite class. So couldn't it be just be declared as private without a property?

I'm very confused on the actual differences between public fields and properties. I know properties let you control the set conditions as well as do calculations in the get part. But all the time in Jaeger's book I see private fields with generic { get; set; } properties. So why does he do that in some cases but not all? I can't see any difference.

[BBeck]

Well, I'll say this. The more I learn about Packt publishing the more I think it's three frat boys operating a publishing company out of their basement. They are highly unprofessional.

I really like Kurt Jaeger's website, although I say that having mostly browsed it rather than having actually gone through the tutorials. But I'm afraid I'm going to have to call him out on this one, if he's declaring public fields.

It's just plain wrong to make fields public. I can't really think of a single legitimate reason to do it. If it's the Game1 class it may be to give visibility to the other objects. But especially in any other class, I don't think that's ever correct.

It breaks one of the foundational principles of Object Oriented Programming, Encapsulation:

http://en.wikipedia....ed_programming)

Fields are supposed to be private (or at least not public) because those using the class are not supposed to think of it as code but rather as an object. It is supposed to be controlled by public methods and even methods that don't have to be made public are supposed to be private (or at least not public).

I was very uncomfortable even with getters and setters at first (properties). They come very close to breaking the principle of encapsulation. However, when you follow the principle of encapsulation, you find yourself constantly writing Get and Set methods to allow the user of the object to see and change various values. A lot of times that's more complex than simply equating a value. However, properties address this issue and allow you to create some rather complex "set" (or even get) code.

I think properties arose because getting and setting was so ridiculously common. Between the fact that everyone uses properties these days and the fact that I was constantly writing my own get and set methods, I eventually got pretty comfortable with properties.

Basically, properties are methods and not fields. They are very special "methods" in that they have the ability to act like fields. But in the end, they are much closer to methods than fields. So, it's really the same as declaring your own methods to set private fields. The syntax is just a bit more convienient with properties than doing it as a method.

So, in short, your fields should pretty much always be declared private (or at least not public - protected or protected internal might be appropriate).

Now declaring a public property with nothing but {get; set;} is still a property and not a field. It's just basically a short-cut way to declare the property. Instead of declaring a field and declaring a property to get/set it, you are combining it all into one. Think of it as having a hidden private field that even you don't see. But I think logically and functionally it's still a property, not a field.

I have to admit, I'm not the best at declaring absolutely everything properly myself. We're all kind of still learning this. And we've all got our areas of weakness and our areas of expertise. But it sounds like one of Kurt's weaknesses is Access Modifiers.

[baavgai]

In a nutshell, fields should never, ever, be public in OOP. Period. There is no possible argument for it other than laziness.

The reason to never show raw variables to the world is control. Your object should be the only thing directly messing with such data. That's its job.

There is no fundamental difference between these two:

public Texture2D Texture { get; set; }
public Texture2D Texture; // bad name, .NET vars should always start lower case

That is, no difference now. What if you want to disallow nulls, later on? Or track changes? Have an event raised on change? With your variable, this is not an option. With a property, it's simply a matter of adding code.

[Natman]

Thank you both for your answers. That really cleared a lot up. I guess I'm also confused because I see Jaeger declaring private fields and then just making properties for all of them. Should I automatically make properties for all of my fields or only the ones that will be accessed externally?

[baavgai]

If a variable is private, then it needn't be a property. The class has complete control of the variable's state. It's only when you "expose" the workings of your object to the public that you want to be paranoid.

Also, keep in mind that a variable should only live as long it's needed; and no longer. So, a variable at the object level is needed for the object's state. This is the reasoning behind declaring a variable in the "for" statement [li]for(int i=0; ...[/il]. The loop iterator shouldn't exist outside the loop, so doesn't.

[Natman]

What happens when fields have no access modifiers? I see this all the time in sample code.

[BBeck]

Just because you have a field doesn't mean it should have a matching property. It may be private or protected and used only by the class with no possibility of using it externally. Actually, that would be the normal state of things. Properties or external access to fields is really more the exception. So, just use properties for values that you use externally. If it's internal it should be locked away from external use.

I would have to check MSDN, but I think any value that doesn't specify an access modifier defaults to public.

[baavgai]

When you're not explicit, stating the access, then you're implicit and fall back to defaults. The default for C# is private.

Quote

The access level for class members and struct members, including nested classes and structs, is private by default.
-- http://msdn.microsof...y/ms173121.aspx

The original C# was basically Java for Windows. It seemed that C# benefited greatly from prior experience in Java. The Property instead of the getter setter convention is one example. Another improvement was the implicit access.

Quote

If a class has no modifier (the default, also known as package-private), it is visible only within its own package (packages are named groups of related classes
-- http://docs.oracle.c...esscontrol.html

Translation, in Java default is public within the package. This is explicitly declared as "internal" in C#.

[Ryano121]

baavgai, on 15 September 2012 - 11:05 AM, said:

In a nutshell, fields should never, ever, be public in OOP. Period. There is no possible argument for it other than laziness.

What about constants? Wrapping them in a property is just a waste of time.

Edit - I suppose constants are really 'constant fields' and not just fields so scrap that.

This post has been edited by Ryano121: 16 September 2012 - 11:02 AM