[Discussion] About the use of Get/Set methods.

A couple of collegues om me and I myself have started some discussion about what would be the proper use for get/set methods from within your class itself. So let's start with an example:

type
  TSomeClass = class(TObject)
  private
    FSomeProperty: Integer;
  protected
    function GetSomeProperty: Integer;
    procedure SetSomeProperty(const Value: Integer);
  public
    procedure SomeAction;
    property SomeProperty: Integer read GetSomeProperty write SetSomeProperty;
  end;

Okay, we have a class, a property, a get method, a set method and a variable containing the data behind the property. Assume the get/set methods will do some additional processing of the data.

Now, the SomeAction method is doing some processing on the value in this property. Maybe something mathematical or whatever. Not important. What is important is how to decide which method is best for calling this all. Three options:

Option one: access through the property:
procedure TSomeClass.SomeAction;
var
  Data: Integer;
begin
  // Get the value
  Data := SomeProperty;
  // Some action
  Data := Data + 1;
  // Set a value back
  SomeProperty := Data;
end;

Option two: access through the get/set methods
procedure TSomeClass.SomeAction;
var
  Data: Integer;
begin
  // Get the value
  Data := GetSomeProperty;
  // Some action
  Data := Data + 1;
  // Set a value back
  SetSomeProperty(Data);
end;

Option three: access through the variable:
procedure TSomeClass.SomeAction;
var
  Data: Integer;
begin
  // Get the value
  Data := FSomeProperty;
  // Some action
  Data := Data + 1;
  // Set a value back
  FSomeProperty := Data;
end;

And thus started the discussion about which of these three solutions would be the best one to use. And more importantly, getting the right arguments to defend a certain method. Since it resulted in quite a discussion at my job place, I thought it would be fun to have a similar discussion here... :-)

So okay, experts. Let's hear your best arguments!

(Since this question has no good answer, points will be divided over every good argument. Question will be closed once the arguments have stopped for more than two weeks.)
LVL 17
Wim ten BrinkSelf-employed developerAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
2266180Connect With a Mentor Commented:
I personally never use the set/get methods directly from my class. instead I use the property when I need to make sure that the extra processing (current or added in the future(!)) will take place and accessing teh raw data whenever I want to make sure that that extra processing (current or added in teh future) will not take place.
as ziolko said: it's a matter of deciding what you do internally with your data.
thoough in any case I do not see any reason against using get/set or only the property itself other then maybe performance wise. some people what to see details, some dont. properties hide details. I personally hate to see details when I don't need them (inside the class itself). and outside the class ... I always make the setter and getter methods private anyway :D
0
 
ziolkoConnect With a Mentor Commented:
hmm well I think options 1 and 2 it's matter of Your choice and consequence for me personally SomeProperty := Data is easier to read but other may claim that SetSomeProperty(Data) clearly shows that some extra processing wil be done.
In case of option 3 thats a little bit different and I think stronlgy depends on that magical "extra processing" in other words sometimes You might not want to do extra processing but only change "raw" data.

ziolko.
0
 
TheRealLokiConnect With a Mentor Senior DeveloperCommented:
I have to agree.
If I need the "extra processing" to occur, I'd call the property "SomeProperty"
If I only need to change the value I set fSomeProperty
0
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
kretzschmarConnect With a Mentor Commented:
option 1 and 2 are ok, they are equal
option 3, i would avoid(because of additional processing in the getter/setter), except i myself be sure about what i do

meikl ;-)
0
 
Eddie ShipmanConnect With a Mentor All-around developerCommented:
I wouldn't even HAVE Get/Set methods for a simple property, like an integer type, unless I had
to do something else with the value or manipulate the value before returning it.

The only reason to have them is for any extra processing that needs to be done IN ADDITION to
setting or getting the value of the property. In the case above, it is definately not needed.

This is much easier way to do it:
  property SomeProperty: Integer read FSomeProperty write FSomeProperty;

Then you use the variable .vs the property when assigning a value in your own class so Option 3 is
the preferable way to do it in this case.
0
 
Wim ten BrinkSelf-employed developerAuthor Commented:
Good arguments, all. But okay, let's focus on methods 1 and 2 for now, assuming that you also need the extra processing from within your class. Which option would be the preferred one?

I've had three collegues voting for using get/set calls instead of using the properties and one collegue plus me who prefer using just the property. Quite a few arguments have come by, including readability and whatever more. Made for an interesting discussion.

So, if you have to choose between option 1 and 2, which one would you prefer and most importantly, WHY? :-)
0
 
2266180Commented:
as I said, I personally prefer method 1 for detail hiding. if I want to use raw data: FSomeProperty. if I want processing: SomeProperty. If I see the F, I am sure that I do no processing and if I don't see the F, then it's either some property with the necessary processing or some variable; doesn't matter. in the end, if I do put a getter/setter method with some processing, I usually, generally, in most of the cases want that procesing to be done. so why write some extra characters (even if they are only 3 :P) when you can have the simplicity of using a property?
and more: lets say that now I have:

type
  TSomeClass = class(TObject)
  private
    FSomeProperty: Integer;
  public
    property SomeProperty: Integer read FSomeProperty write FSomeProperty;
  end;

and in code I use SomeProperty everywhere I don't want to explicitly work with the raw data. effect? if the client wakes up one morning (and they tend to do so) that "hey, what if we put validation on all fields?" then all you need to do is do

type
  TSomeClass = class(TObject)
  private
    FSomeProperty: Integer;
  protected
    function GetSomeProperty: Integer;
    procedure SetSomeProperty(const Value: Integer);
  public
    property SomeProperty: Integer read GetSomeProperty write SetSomeProperty;
  end;

and you are done. no need to change the code.
BUT, if you are used to working with getters/setters, you will most likely end up using the raw data everywhere instead of the property (since you are in your own class and you don't have a get/set to use) (seen this => lot of headache) and when you will end up needing processing ... you will have a hell of a lot of places to fix your code and it WILL generate bugs as you will surely miss one or two places.

so I go with option 1 for simplicity and (future) assurance.
0
 
ziolkoCommented:
if I had to choose between options 1 and 2 I would choose number one because... I don't know maybe because it's easier to read (esp. after some time not working with specific project) or simply because I got used to it, and any change of good habit ends up with smaller or greater disaster ;)

ziolko.
0
 
Eddie ShipmanAll-around developerCommented:
While, I do not have the asm to show you but it is likely that 2 is the one that takes the least processing
time due to having to look up the address of the variable in No. 1.

I think, overall, it is personal preference, here. Since I have written/modified a good number of components,
I tend to use the same conventions used by Borland, which is no. 3.
0
 
Eddie ShipmanAll-around developerCommented:
In my first sentance, I meant no. 3, not no. 2.
0
 
Wim ten BrinkSelf-employed developerAuthor Commented:
Thank you all for the good points made in this discussion. :-)

Apparantly, there is no clear standard although most seem to favor calling the property instead of the get/set methods whenever they need the additional processing. :-)
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.