[AccessD] Access and OOP

John Colby jwcolby at gmail.com
Mon Aug 31 07:22:46 CDT 2020


If you were to interview with the mythical organization C2Db for an Access
position, I would ask you:

1) Do you understand OOP?
Yes.  The only acceptable answer in 2020.
2) What is a class? A code construct that allows you to model a real world
object, encapsulating code and variables (and events) for that object.
Good answer.
3) Can you model more than one object in a class?
No.  A class models one object.  Good answer.
4) In Access, do you use a form class to contain code, data and event
handling for controls?
Yes.  Wrong answer.

A form class is used to model a form.  If you use a form module to contain
data, methods and event handlers for a text box, now the form module is
modeling a form and a text box.  This is a fundamental error in OOP.
Now you add data, methods and event handlers for combos, lists, radio
buttons, check boxes, and who knows what else and what do you have?  A very
non OOP mess.

Let's suppose that you have a form with 4 combo boxes and 10 text boxes.
You want all the combos to raise 5 events.  OnEnter, OnExit, OnGotFocus,
OnLostFocus and OnDblClick.  Your poor form now has 20 event sinks for
those 4 combo boxes.  Assume that you want the text boxes to have event
sinks for the first 4 events.  You have kjust added 40 new event handlers
for those 10 text boxes.  Assume that you want to store one property (the
background color) for each of those controls.  You now have 14 variables
created in the header of the form class.

Did I mention an OOP mess?  That is what I mean by an OOP mess.

How many developers have opened a form designed (by someone else) where the
form class, when printed, has code which runs out in the hall, out the door
and down to the stop sign at the corner?  Yep, an OOP mess.  How many of
you have opened a bunch of forms and seen exactly the same code across all
of those forms.  Yep, an OOP mess.

Are you that developer?

Access provides us with a tool for this exact problem.  It is called a
class.  A class can be passed a pointer to a combo box and that instance of
the class now contains all of the data, code and event handling for that
instance of that specific combo box.  That instance sinks events for
exactly that instance of a combo, has variables for that instance of that
combo.  has code for combos.

Can a form class hold all the code for every thing you might want to put on
a form.  Yes.  Do you instantly have an OOP mess?  IMHO yes, you do.

And finally, classes in Access are very similar to classes in any other
language.  They serve the same purposes.  They exist.  They should be used
to solve those problems.

Just MHO of course.

There are many OOP choirs out there.  The C# OOP choir is different from
the Java OOP choir which is different from the Python OOP choir and from
the Access OOP choir.  But in order to be in the OOP choir, you must be
using classes.  Classes are the foundation of OOP.  They solve a very real
problem.  They are all the rage, but for very good reasons.  Access is not
immune to the problems that OOP is designed to fix.

I have provided examples of many different uses for classes in the examples
I posted on GitHub.
-- 
John W. Colby
Colby Consulting


More information about the AccessD mailing list