Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Class Methods vs Procedures and Functions in a Library Type Unit


This question is answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 9 - Last Post: May 8, 2015 5:28 AM Last Post By: Andrea Raimondi Threads: [ Previous | Next ]
tim crouse

Posts: 83
Registered: 2/11/02
Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 29, 2014 10:38 AM
As someone learning the OOP aspect of Delphi I have this question:

I know there are many ways to do the same thing in Delphi, this question pertains to the use of procedures and creating a library of procedures for re-use throughout multiple projects.

I understand I can have a unit that holds code I can re-use. What is the difference between having access to procedures and functions stored in a unit but not in a class through the USE declaration

OR

Creating instances of class objects that have methods (functions and procedures) declared inside of them.

I understand the basics of the benefit of strictly Typed objects when it comes to assigning an object type to a variable.

But I loose sight of the benefit of having a class with procedures and functions vs just having access to procedures and function through a unit.

Perhaps in simple applications using the unit approach is acceptable but I would really like to learn an approach that will lend itself to more complex scenarios.

Thanks in Advance
Tim C.

Linden ROTH

Posts: 467
Registered: 11/3/11
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 29, 2014 12:56 PM   in response to: tim crouse in response to: tim crouse
tim crouse wrote:
As someone learning the OOP aspect of Delphi I have this question:

I know there are many ways to do the same thing in Delphi, this question pertains to the use of procedures and creating a library of procedures for re-use throughout multiple projects.

I understand I can have a unit that holds code I can re-use. What is the difference between having access to procedures and functions stored in a unit but not in a class through the USE declaration

OR

Creating instances of class objects that have methods (functions and procedures) declared inside of them.

I understand the basics of the benefit of strictly Typed objects when it comes to assigning an object type to a variable.

But I loose sight of the benefit of having a class with procedures and functions vs just having access to procedures and function through a unit.

Perhaps in simple applications using the unit approach is acceptable but I would really like to learn an approach that will lend itself to more complex scenarios.

Thanks in Advance
Tim C.


Tim

I tend to use CLASS procedure and functions
1) It helps naming eg MyCommonStuffForX.add5
2) Class vars are not really global
3) Later I might what an actual object so can enhance easier

--
Linden
"Mango" was Cool but "Wasabi" was Hotter but remember it's all in the "source"

Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 4, 2014 11:32 PM   in response to: Linden ROTH in response to: Linden ROTH
Linden ROTH wrote:

2) Class vars are not really global

Yes, they are.

--
Rudy Velthuis http://www.rvelthuis.de

"We will not learn how to live together in peace by killing each
other's children." -- Jimmy Carter

Eli M

Posts: 1,346
Registered: 11/9/13
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 29, 2014 3:30 PM   in response to: tim crouse in response to: tim crouse
It would keep procedure name conflicts from happening too though overloading is supported.
John Treder

Posts: 349
Registered: 8/2/02
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Nov 29, 2014 5:24 PM   in response to: tim crouse in response to: tim crouse
tim crouse wrote:

I know there are many ways to do the same thing in Delphi, this question pertains to the use of procedures and creating a library of procedures for re-use throughout multiple projects.

I understand I can have a unit that holds code I can re-use. What is the difference between having access to procedures and functions stored in a unit but not in a class through the USE declaration

OR

Creating instances of class objects that have methods (functions and procedures) declared inside of them.

You'll find that there are reasons to have a library of plain procedures and functions. The Math unit is a classic example.
You'll also find that when you're creating an application that does something you might be interested in or need to do,
the encapsulation provided by classes and class hierarchies can be invaluable. In a class, you can have a whole bunch of stuff going on, and just call MyClass.DoMyThing(Lefthanded);
It took me, back in the early 80s, a year or more to get my head wrapped around the idea of classes and encapsulation.
Then Windows came along. A whole new learning curve. So don't give up!

--
Ol' Tred

> Rich <

Posts: 171
Registered: 2/6/09
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 1, 2014 9:14 AM   in response to: tim crouse in response to: tim crouse
tim crouse wrote:

Perhaps in simple applications using the unit approach is acceptable but I would really like to learn an approach that will lend itself to more complex scenarios.

They both sure are fun! Consider this: You have a unit that has some function that does something. You want to track how many times that function is called and maybe a bit of information about the results the function returns. If you use a function library where will the additional statistics about the function's use reside? If you use an object then those statistics would be stored and accessed via the object.

1. Library function:
function calculatebalance(AccountID: Integer): Real;

2. Object:
BalanceCalculator = class
private
Called: Integer;
AverageBalance: Real;
public
function CalculateBalance(AccountID: Integer): Real;
end;

With the library function you have a nice small and fast function. With the object you have something live in the system that can do more than just return a result. But, again, they are both fun.
Kirk Halgren

Posts: 1
Registered: 8/27/97
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 1, 2014 10:49 AM   in response to: > Rich < in response to: > Rich <
> Rich < wrote:
tim crouse wrote:

Perhaps in simple applications using the unit approach is acceptable but I would really like to learn an approach that will lend itself to more complex scenarios.

They both sure are fun! Consider this: You have a unit that has some function that does something. You want to track how many times that function is called and maybe a bit of information about the results the function returns. If you use a function library where will the additional statistics about the function's use reside? If you use an object then those statistics would be stored and accessed via the object.

1. Library function:
function calculatebalance(AccountID: Integer): Real;

2. Object:
BalanceCalculator = class
private
Called: Integer;
AverageBalance: Real;
public
function CalculateBalance(AccountID: Integer): Real;
end;

With the library function you have a nice small and fast function. With the object you have something live in the system that can do more than just return a result. But, again, they are both fun.

Tim,
Why not use a staged approach? Use the shared unit to start with, then later if you see a good reason to encapsulate those functions into a class, simply move them to the class. By then you'll have a better feel for which functions naturally group together which makes a more coherent class. I have yet to use it but IIRC Gxperts has a renaming feature that would simplify changing the references in your existing code from the unit approach to the object one. If you keep the new object in the same unit, you wouldn't have to change any of the uses clauses.

Kirk Halgren
Picard and Dathon on El-Adrel
Nyad walking up Smathers Beach
tim crouse

Posts: 83
Registered: 2/11/02
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 1, 2014 11:15 AM   in response to: Kirk Halgren in response to: Kirk Halgren
All Good Insight

Thank You


Kirk Halgren wrote:
> Rich < wrote:
tim crouse wrote:

Perhaps in simple applications using the unit approach is acceptable but I would really like to learn an approach that will lend itself to more complex scenarios.

They both sure are fun! Consider this: You have a unit that has some function that does something. You want to track how many times that function is called and maybe a bit of information about the results the function returns. If you use a function library where will the additional statistics about the function's use reside? If you use an object then those statistics would be stored and accessed via the object.

1. Library function:
function calculatebalance(AccountID: Integer): Real;

2. Object:
BalanceCalculator = class
private
Called: Integer;
AverageBalance: Real;
public
function CalculateBalance(AccountID: Integer): Real;
end;

With the library function you have a nice small and fast function. With the object you have something live in the system that can do more than just return a result. But, again, they are both fun.

Tim,
Why not use a staged approach? Use the shared unit to start with, then later if you see a good reason to encapsulate those functions into a class, simply move them to the class. By then you'll have a better feel for which functions naturally group together which makes a more coherent class. I have yet to use it but IIRC Gxperts has a renaming feature that would simplify changing the references in your existing code from the unit approach to the object one. If you keep the new object in the same unit, you wouldn't have to change any of the uses clauses.

Kirk Halgren
Picard and Dathon on El-Adrel
Nyad walking up Smathers Beach
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Dec 5, 2014 12:22 AM   in response to: tim crouse in response to: tim crouse
tim crouse wrote:

As someone learning the OOP aspect of Delphi I have this question:

I know there are many ways to do the same thing in Delphi, this
question pertains to the use of procedures and creating a library of
procedures for re-use throughout multiple projects.

I understand I can have a unit that holds code I can re-use. What is
the difference between having access to procedures and functions
stored in a unit but not in a class through the USE declaration

OR

Creating instances of class objects that have methods (functions and
procedures) declared inside of them.

I understand the basics of the benefit of strictly Typed objects when
it comes to assigning an object type to a variable.

But I loose sight of the benefit of having a class with procedures
and functions vs just having access to procedures and function
through a unit.

The main advantage of a class with a static method is that the method
is tied to the scope of the class. But that is also its main
disadvantage.

If, instead of

X := Sin(2 * Pi * X);

you have to call

X := Math.Sin(2 * Math.Pi * X);

every time, a class with static methods loses its advantage, IMO. This
is generally only done in languages that do not have global (i.e.
non-method) functions or procedures.

I usually only have static methods if the methods are related to (the
functioning of) that class.

I have a BigInteger class that has a static method called SetBase,
because the numeric base for input and output can only be 2..36, any
other value is not accepted. The base itself is a private class
variable. I also have static methods that can negate, sign-extend, etc.
the multi-limb number in a given dynamic array, which are used by
several instance methods.

Otherwise, especially if they are functions that are not releated to
some specific class or problem domain, there is nothing wrong with
plain library functions, like Sin(), Pos() or Format(). There is no
need to tie them up in class.

--
Rudy Velthuis http://www.rvelthuis.de

"War doesn't make boys men, it makes men dead." -- Ken Gillespie
Andrea Raimondi

Posts: 3
Registered: 4/13/00
Re: Class Methods vs Procedures and Functions in a Library Type Unit  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 8, 2015 5:28 AM   in response to: tim crouse in response to: tim crouse
Hi!

First off, sorry for being late to the party :)

You have several viable options:

1) All rountines (procedures/functions)
2) Static methods (class procedures/functions)
3) Classes

Each has a different kind of usage:

1) Routines
This is the "classic" pascal way. Very useful if said routines do not change often or if you already have a large base of code which employs them.
2) Static methods
This is useful when you have to group together some things but you do not have a "single responsibility" per se. This is useful for cases like
TEditorUtils.FromPointToCursor( X,Y, Cur ); in an editor control. They can be virtual, so they can be extended if need be.
3) Classes
This is useful when a set of routines always gets called together to obtain some kind of result. A typical example is TForm which
hides calls to CreateWindow, CreateWindowParams, etc. It can be overridden.

So, what is that you are trying to do? Are you trying to do something which is likely to change and/or apply to something else?
If so, you should choose 2 or 3 according to your situation.

Otherwise go for 1.

GOTCHA: When you use classes, the code inevitably slows down a bit because of the calls to the VMT and other stuff.
There are situations where this is not ideal and you need the raw power of procedures and functions.
If that's the case, go with 1.

A
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02