Accessor methods vs public variables

[mnemonic]

How do you decide on whether an attribute of a class is public or has an accessor method?

For example, a Cody class could be written in two ways (I'm not including variables that you create / modify with get / set methods):

Code: C# [Select]

1. class Cody {
2.         public string colour = white;
3.         public int age = 10;
4. }

Code: C# [Select]

1. class Cody {
2.         private string colour = white;
3.         private int age = 10;
4.  
5.         public void setColour(string colourIn) {
6.                 this.colour = colourIn;
7.         }
8.  
9.         public string getColour() {
10.                 return this.colour;
11.         }
12.  
13.         public void setAge(int ageIn) {
14.                 this.age = ageIn;
15.         }
16.  
17.         public int getAge() {
18.                 return this.age;
19.         }
20. }

Do you just create accessor methods (is that the correct term?) for those attributes that are likely to be complex or may need transformation, or do you create them for everything and leave nothing public?

[mouser]

Modern programming practices tell you to always use accessors when manipulating or retrieving variables from outside of the class itself.
In general, a class should not allow anyone to mess with its insides directly.

This makes good common sense as well -- an object/class should be able to implement whatever gatekeeper or background functions that it wants to, with complete confidence that it knows when people are reading its values or changing them, and has the opportunity to intercept such requests if it needs to.

The only exception to this would be if you were working with code that absolutely had to be as fast as possible and you couldn't be sure the compiler was going to optimize the accessor access code.

[mnemonic]

Ok, so you never use public attributes in classes unless speed is absolutely vital?

[mouser]

Ok, so you never use public attributes in classes unless speed is absolutely vital?

if your question is:

so one never uses public attributes in classes unless speed is absolutely vital?

then the answer is: correct.

if your question is:

so you never use public attributes in classes unless speed is absolutely vital?

then the answer is: no comment.

 

[mnemonic]

Don't worry, what happens in Donationcoder stays in Donationcoder 

Thanks for the answers 

[f0dder]

Ok, so you never use public attributes in classes unless speed is absolutely vital?

-mnemonic (June 13, 2009, 04:55 AM)

You never use publicly accessible attributes, period. And forget the speed argument, compilers are pretty decent at inlining the calls so they end up with exactly the same machine code as direct access.

Heck, you should even use accessor methods in the class methods as well... for simple stuff it doesn't really matter, but for more complex code it allows you to introduce caching instead of re-computation etc.

[mnemonic]

Heck, you should even use accessor methods in the class methods as well... for simple stuff it doesn't really matter, but for more complex code it allows you to introduce caching instead of re-computation etc.

-f0dder (June 13, 2009, 08:51 AM)

Can you explain what you mean by this? 

[MilesAhead]

Other than the "rules" arguments, there's the benefit that you can change the implementation without breaking code that's the client of the class.  IOW, if you use a Property to get a bitmap, the client won't break if you later decide to load the bitmap from a file instead of a resource that's compiled in.  Gives you some flexibility.

Plus the benefit of being able to "screen" the values that would modify the variable. A simple example might be a number used as a divisor.  If the value used in the attempted modification is zero, some other action rather than CPU trap is advisable.