topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 6:34 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Accessor methods vs public variables  (Read 7125 times)

mnemonic

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 177
    • View Profile
    • My website
    • Donate to Member
Accessor methods vs public variables
« on: June 13, 2009, 04:44 AM »
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

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #1 on: June 13, 2009, 04:51 AM »
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.
« Last Edit: June 13, 2009, 04:54 AM by mouser »

mnemonic

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 177
    • View Profile
    • My website
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #2 on: June 13, 2009, 04:55 AM »
Ok, so you never use public attributes in classes unless speed is absolutely vital?

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 40,896
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #3 on: June 13, 2009, 05:06 AM »
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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 177
    • View Profile
    • My website
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #4 on: June 13, 2009, 05:08 AM »
Don't worry, what happens in Donationcoder stays in Donationcoder  ;)

Thanks for the answers  :Thmbsup:

f0dder

  • Charter Honorary Member
  • Joined in 2005
  • ***
  • Posts: 9,153
  • [Well, THAT escalated quickly!]
    • View Profile
    • f0dder's place
    • Read more about this member.
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #5 on: June 13, 2009, 08:51 AM »
Ok, so you never use public attributes in classes unless speed is absolutely vital?
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.
- carpe noctem

mnemonic

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 177
    • View Profile
    • My website
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #6 on: June 13, 2009, 05:12 PM »
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.

Can you explain what you mean by this? 

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 7,736
    • View Profile
    • Donate to Member
Re: Accessor methods vs public variables
« Reply #7 on: June 13, 2009, 05:33 PM »
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.