Re: Class fog in my brain

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Larry Serflaten (serflaten_at_usinternet.com)
Date: 05/28/04 

Date: Fri, 28 May 2004 05:57:21 -0500

"Tom_OM" <dontspamme@junkmailstinks.com> wrote
>
> I have no doubt that class modules are useful; I'm just not getting
> them yet.

It is quite simple, really. Beginning with the basics:

You have variables that hold your data, and modules that hold your code.

On the variable side, you can create variables of different types, you can
create arrays of those different types, or, you can create a User Defined
Type that is a mixture of different data types, and finally you can have
arrays of those UDTs.

On the modules side, you have a BAS module that contains variables
and code, and you have forms that contain variables and code. The
form is a special case in that it is bound to a visible representation of
different windows (form, controls, etc... are 'windows') and other
windowless controls (Line, Shape, Lable).

OK, you know about those.

Consider, then, what the button is. It is a control that has properties,
methods, and events. When you put one on the form, the designer
shows the visible representation of it, and the code module will show
its events. You can set its properties in the Property window, and can
respond to its events in the code module.

But, if you add a second button to the form, you get a completely new
button, that has its own properties, methods, and events. How is that done?

For a second example, suppose you have a UDT that has data pertaining
to an employee in your latest HR manager program. Now suppose the
UDT has an a array of StartTimes, and EndTimes to help calculate the
weekly pay of that employee. Also suppose that the company has workers
that work in shifts, such that they can run 24/7 using 3 teams working
8 hour shifts and anyone who works outside of their designated shift
gets overtime pay.

Now consider you use this same employee data in your HR program,
and your accounting program, and your resource management program
plus a few others. Should all these different program supply their own
BAS module to calculate wages or to report work hours outside of their
regular shift schedule?

What if you could include a method in with the employee data that would
return the weekly pay amout, or total overtime hours worked. Wouldn't
that make it easier for the HR, and accounting, and CRM (etc.) programs
that need to handle employee data?

The problem is, if you update the HR program to say the new rule is that
not only is overtime outside of the regular shift, but it also can only be
applied when the employee has worked over 40 hours that week. So, you now
have a new rule that has to go into your accounting, and CRM, and any
other programs, right?

If you could keep that rule with the data, it would make things easier
because you would update the employee code, and every program that
uses the employee would automatically see the change.

But what is that employee code? Thats where classes fit in. They
extend the UDT to allow you to add methods and properties to your
data. Like a UDT you can store all sorts of data in a class, and like the
button, you can create as many as you need, and they each get their own
data, methods, and events. And, a bit like control arrays, you only have
to write code in one area to effect all the objects of that type.

The beauty is that you only write the code in one class, and at runtime that
class is created as an object, where you can make as many copies as you
need.

So now, all your programs use the employee object, that has an OverTimeHours
function that returns the employee's current overtime hours. When the rules
change, as they were changed above, you only make a change to the employee
object, and that gets propogated out to all the users of the employee object
without the need to add code and recompile those programs to add the new
rule. (Versioning your objects is a topic of another discussion...)

That is about it, in a nutshell, a class is an extention of the UDT in that, in
addition to data, (properties) you can add methods and events to that
group of data. You maximize code re-use (those other programs don't
need to include the BAS module to calculate overtime because it is provided
in the employee object) which is going to help maintain the whole suite of
programs by reducing and encapsulating the required code.

For a simple example, add a class to a new project, and give it two
public (string) properties: FirstName and LastName.

Then give it a public function called FullName:

Public Function FullName() As String
  FullName = FirstName & " " & LastName
End Function

And another called SortingName

Public Function SortingName() As String
  SortingName = LastName & ", " & FirstName
End Function

This is a ficticious example, but just to get used to the idea,
try it out, and use it in code, just to play with it a little:

Private People(0 To 2) As Class1 ' < Default name of your class

Private Sub Form_Load()
Dim i
  For i = 0 To 2
    Set People(i) = New Class1
    People(i).FirstName = Array("Tom", "***", "Harry")(i)
    People(i).LastName = Array("Ott", "Dan", "Arms")(i)
  Next
  
  Debug.Print People(0).FullName
  Debug.Print People(0).SortingName
End Sub

(For reference, consider this Class1 code:)

Option Explicit

Public FirstName As String
Public LastName As String

Private mAge As Integer

Public Function SortingName() As String
  SortingName = LastName & ", " & FirstName
End Function

Public Function FullName() As String
  FullName = FirstName & " " & LastName
End Function

Public Property Get Age() As Integer
  Age = mAge
End Property

Public Property Let Age(ByVal Value As Integer)
  If Value < 1 Then
    Err.Raise vbObjectError + 1, Me, "Too young to work!"
  End If
  mAge = Value
End Property

There are two parts to a property; the Let and Get parts:

Let part : Class1.Age = 45 ' Assignment to the class
Get part : X = Class1.Age ' Returned value from the class

If you single step through your code, you'd see the different parts
get called for the different assignment lines above.

Do you see how a rule was added to the Age property? You can't do that
with a UDT can you? Yet another reason why they are useful....

FYI: if the property is supposed to be an object, (As Textbox, for example)
then the parts are Set and Get (When using objects, always expect to use Set).

LFS

Quantcast