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 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

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

All Good Insight

Thank You



> {quote:title=Kirk Halgren wrote:}{quote}
> > {quote:title=> Rich < wrote:}{quote}
> > > {quote:title=tim crouse wrote:}{quote}
> > > 
> > > 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

> {quote:title=> Rich < wrote:}{quote}
> > {quote:title=tim crouse wrote:}{quote}
> > 
> > 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

> {quote:title=tim crouse wrote:}{quote}
> 
> 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 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

It would keep procedure name conflicts from happening too though overloading is supported.

> {quote:title=tim crouse wrote:}{quote}
> 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"