Setting object properties vs. passing variables: which is better?

[edvard]

I am doing some refactoring of a program, mainly trying to take large chunks of 'business' code out of 'OnClick' events and put them in an external unit. I was advised on the IRC channel to use objects to make interaction between the two easier, so I read 'Programming Using Objects' from the wiki, and had a lot of fun learning about that.  But I find that I can do things just as easy passing variables to unit procedures without resorting to objects, and it seems cleaner and easier to read.
So... which way would be better, and why?

Compare:
Here we do things with objects:

object_test.pas

Code: Pascal  [Select][+][-]

1. program object_test;
2.  
3. {$mode objfpc}{$H+}
4.  
5. uses
6.   Classes, Unit1;
7.  
8. //pretend this is an 'onclick' event, and the values come from
9. //different button and entry box properties, etc.
10. procedure Click;
11. begin
12.   DoStuff.X := 4;
13.   DoStuff.Y := 7;
14.   DoStuff.This := 'Smells';
15.   DoStuff.That := 'Funny';
16.  
17.   DoStuff.XYcalc;
18.   DoStuff.ThisThat;
19. end;
20.  
21. begin
22.   Click;
23. end.
24.  

Unit1.pas:

Code: Pascal  [Select][+][-]

1. Unit unit1;
2.  
3. interface
4.  
5. uses
6.   Classes;
7.  
8. type
9.   TTestobject = Object
10.     X,Y : integer;
11.     This, That : string;
12.     procedure XYcalc;
13.     procedure ThisThat;
14. end;
15.  
16. var
17.    DoStuff : TTestobject;
18.  
19. implementation
20.  
21. procedure TTestobject.XYcalc;
22. begin
23.   writeln(X*Y);
24. end;
25.  
26. procedure Ttestobject.ThisThat;
27. begin
28.   writeln(This,' ',That);
29. end;
30.  
31. end.
32.  

And here we do the same thing, but pass variables instead of setting object properties:

varpass.pas:

Code: Pascal  [Select][+][-]

1. program varpass_test;
2.  
3. uses
4.   unit1;
5.  
6. //pretend this is an 'onclick' event, and the values come from
7. //different button and entry box properties, etc.
8. procedure Click;
9. var
10.   x,y: integer;
11.   this, that: string;
12. begin
13.   x := 4;
14.   y:= 7;
15.   this := 'Smells';
16.   that := 'Funny';
17.   XYCalc(x,y);
18.   ThisThat(this,that);
19. end;
20.  
21. begin
22.   Click;
23. end.

Unit1.pas:

Code: Pascal  [Select][+][-]

1. Unit unit1;
2.  
3. interface
4.  
5. procedure XYCalc(x,y:integer);
6. procedure ThisThat(this,that:string);
7.  
8. implementation
9.  
10. procedure XYCalc(x,y:integer);
11. begin
12.   writeln(x*y);
13. end;
14.  
15. procedure ThisThat(this,that:string);
16. begin
17.   writeln(this,' ',that);
18. end;
19.  
20. end.
21.  

 

[edvard]

I may have a partial answer to my own question: size and speed.
Compiled, the object example is 704.5 kB, while the variable passing example is 176.8 kB.
Quite a difference, but if the reasons for using object property setting are compelling, then size isn't all that much of a concern.
Just did a benchmark... the variable passing example also executed faster. 

[Leledumbo]

None is "better", it's context dependent is affected with the way you structure your code. For instance, to me, passing 8 parameters is now way convenient for a function call. Imagine if TProcess is designed that way, and I need to pass around the process object, that would be incredibly inconvenient. However, parameter passing is faster time because of the default calling convention passes parameters through registers first, before resorting to memory. Properties, OTOH, behaves the same as global variable (which resides in memory) or worse (because properties can be mapped to function call, which adds even more slowness).

[sfeinst]

There is no correct answer.  It depends on coding style.  Your first example is object-oriented, the second is procedural.  And even within the object-oriented style there is disagreement of whether or not you should be setting values.  Some developers believe, you have a constructor to pass values and you only call methods which perform actions.

But for your question, you are just converting code as opposed to knowing the benefits of objects vs procedures (or vice versa depending on your preference).  So you should read up a little on why some people think objects are a better way of coding and reading up on why some people think procedures are better.  Just Google "object oriented vs procedural programming" and you will get tons of hits.

But don't look for the "correct" answer.  If there was one, everyone would be doing it.

[edvard]

Thank you for your advice.  I am a novice programmer and every bit helps. I kinda figured I would get an answer along the lines of "it depends on your coding style" and that's OK. I still need to develop my own preference, but at the same time, being self-taught, I don't want to inculcate bad programming habits, which is part of the reason I'm asking is because parts of my code are quite the mess, even if it works fine.

...
Properties, OTOH, behaves the same as global variable (which resides in memory) or worse (because properties can be mapped to function call, which adds even more slowness).

And that's good enough reason to go with procedural for this part of the code.  I am trying to get rid of all my global variables, after all...

... you are just converting code as opposed to knowing the benefits of objects vs procedures (or vice versa depending on your preference). 

You got that right, I DON'T yet know the benefits of one versus the other, which is why I decided to ask before committing.  Thanks for clarifying that the real issue is object-oriented vs. procedural, I know where my study track lies now.

[SymbolicFrank]

The main benefit is in the encapsulation.

The idea is not to set all those properties, but to let the class figure out by itself what to do.  Make all those properties private, and just tell the class what you expect of it.

Like delegating.

[edvard]

And even within the object-oriented style there is disagreement of whether or not you should be setting values.  Some developers believe, you have a constructor to pass values and you only call methods which perform actions.

The main benefit is in the encapsulation.
The idea is not to set all those properties, but to let the class figure out by itself what to do.  Make all those properties private, and just tell the class what you expect of it.
Like delegating.

And therein lies part of the problem... I have no idea (yet) how to do these things.  I'm still reading up on Classes/Objects, still a little shaky on the concepts, but variable passing to procedures makes sense to me, so I'm rolling with that for now.  However, if you have links for relevant pages that I can learn from, I would greatly appreciate it.

[mangakissa]

Procedures and function are created for one time solution to create something and giving the result back.
A class is an encapsulation of several things witch can do complex things in his own view. When asked the result can be given. Also a class can be declared as several objects. The procedures/events are shared from the class and the variables are declared separately in memory.
Using classes makes your main unit small and readable. You decided creating a class when the procedure / function will be complex.

[avra]

if you have links for relevant pages that I can learn from, I would greatly appreciate it.

https://www.google.rs/search?q=delphi+oop+first+steps

You will not understand what are the benefits of OOP if you don't study the topic.

[cdbc]

Hi
Maybe these links can help:
1) http://delphi.about.com/od/course/a/oop_intro.htm
2) http://www.marcocantu.com/
Regards Benny

[edvard]

Hi
Maybe these links can help:
1) http://delphi.about.com/od/course/a/oop_intro.htm
2) http://www.marcocantu.com/
Regards Benny

Ah yes, I had forgotten about the About.com Delphi course.  Going through it now...