OOP in Access Applications

[SparklySpartan]

Hi everyone,

I have more of a theoretical question today, I'm mostly looking for inspiration on how I might be able to take advantage of the OOP paradigm in the application I'm working on. I guess the general and very open ended question I have is this:

"Can I have some examples from fellow Access programmers of how you've utilized classes and OOP in your databases to write more effective and easy to maintain code? Is there even any such thing as coding using the OOP paradigm in Access?"

Here's What Lead Me to Ask This if It Seems Random...
This came into my mind as I was working on planning out some behavior for two different forms of mine. I realized that there's a field I want to be able to change on two different forms called "Due_Date". I also have a "Reminder_Date" concept in a different field, whenever the Due_Date field gets changed, I want to automatically change the Reminder_Date as well such that the days between them remain consistent. If I bump the due date up 5 days, the reminder date gets bumped up 5 days as well to maintain the distance between them. This is by no means hard to do, but to the best of my knowledge, I would have to write the same code in two places, or (better of course) have a subroutine that does this and gets called in two places.

The same subroutine getting called in multiple places isn't the end of the world, but what if in the future there's another form that changes the due date, and another? I would have to continuously remember to add calls to the subroutine or otherwise get inconsistent behavior throughout my application.
I sort of wish there was a way to define a protocol, every time I change the Due_Date field, independent of the form I changed it from, I want this behavior to occur.

I'm curious of there's some clever way to structure my codebase to allow for this kind of thing. Please, correct me if I'm wrong, because I am no OOP expert at all, but this is one of the many strengths of OOP that I think I understand, the ability to restrict access to changing data to a certain context, where I can define a consistent set of behaviors that will happen alongside that even every time it happens.

Please let me know your thoughts. Is this kind of program structure even viable in an Access application? Even if I'm way off base with my idea that OOP can help solve my two field situation, I'm still curious about the answers to my super general question at the top of this post, because I want to understand more the tools under my belt by seeing the clever ways others have used them.

Thanks a lot, as always! God bless!

 

[Mike Krailo]

These sort of thoughts happen to every programmer. We all want to refactor, make it more efficient, or make reusable code. So it might be fun for you to post the actual code you are using as an example and others can join in discussing how best to make the code reusable.

I know there others who never use classes, and some that use them quite a bit. If classes are used in the right way, they can be quite powerful. I would try and go for the simplest solution that you can work with. The scenario you describe sound very specific to your application. Would you envision many times where you have two or more forms that have a due_date field that needed to stay in synchronization? That seems to be the basic idea of what you want to do with the added ability to also add an offset date value for the reminder dates.

If multiple forms need to see the same due_date, and same offset that suggests a master_due_date variable and a simple reminder_offset variable. These could be tempvars or values in a special table for this purpose. The fields in your form can reference those variables and set those variables. Just an idea for you to consider, but you know what your after and I don't, yet.

 

[moke123]

sounds like you may want a data macro on the table.

 

[MajP]

VBA can do partial OOP (OOP light). There are four basic principles of OOP. You can google these for the details.
Abstraction
Encapsulation
Inheritance
Polymorphism.

VBA classes do abstractions and encapsulation well. There is no inheritance in VBA custom classes although I think there is some version of this in VBA built in classes. For Example you have a Control object and a sub class such as a Text Box, Combo Box etc. I just cannot make my own custom sub classes. Without inheritance there is not really any Polymorphism. Except again with built in classes.
Dim x as Control 'defined it as a generic control
Set x = me.comboBox1 ' instantiate as a sub class
You can kind of build an interface in VBA, but it is so kludgy I am not sure what it really gives you.

However there are a ton of things that can be accomplished by just the first 2 principles. Every time you build a form or report you are using some principles of OOP. These are classes like any other class.

"Can I have some examples from fellow Access programmers of how you've utilized classes and OOP in your databases to write more effective and easy to maintain code? Is there even any such thing as coding using the OOP paradigm in Access?"

I doubt I have ever built a real access database that did not rely heavily on OOP principles and especially custom classes. Many of the databases I have built would be near impossible to build without custom classes (or at least it would be extremely complicated and cumbersome).

Many of the custom class examples people do is to extend the functionality of a control and in ways make a user control

Developing Custom Classes to Simulate User Controls

Access OOP examples wanted Some people have shown interest in custom classes lately, and was asked for some more examples. I use custom classes extensively, but the most important use in Access is the ability to extend control functionality and basically simulate building a user control. Once...

www.access-programmers.co.uk

Any of the examples listed in this thread would be near impossible to have done without extensive use of custom classes and the features they provide (ability to raise custom events, ability to trap external events, ability to instantiate and manage custom collections, class composition)

Scrabble and Drag / Drop Class

@murray83 started to demo a scrabble game here. https://www.access-programmers.co.uk/forums/threads/wordweave-scrabble-just-got-a-makeover.332897/ I had a class I have been using to demo moveable controls. I thought I could do something with that. I wanted to see if I could use some "drag and...

www.access-programmers.co.uk

Here is another recent one that would be near impossible to have done (or at least I would not want to do it) without thorough understanding.
of OOP principles, class objects, and custom classes.

Access Item Genie demo for Organizing / Tracking your Items

This demo was asked by @Mike Krailo if using an Acess Treeview could you do some of the functions of the Utility https://itemgenie.com/ He and I have been working together to make this a useable utility and demonstrate a lot of functionality using a Treeview. Some background here...

www.access-programmers.co.uk

Go ahead and crack the code on any of these and think how you could replicate this functionality without custom classes. I could not.

 

[MajP]

The same subroutine getting called in multiple places isn't the end of the world, but what if in the future there's another form that changes the due date, and another? I would have to continuously remember to add calls to the subroutine or otherwise get inconsistent behavior throughout my application.
I sort of wish there was a way to define a protocol, every time I change the Due_Date field, independent of the form I changed it from, I want this behavior to occur.

This is pretty much seen in all of those examples I posted (and probably a thousand other posts from me on this forum).
A common one demonstrating this is my find as you type combobox. This class changes any combobox into a find as you type combobox. It provides many methods, properties, and features. Most importantly is listens to the events of the combobox. All the user has to do is instantiate a FAYT variable and then initialize it.

You would do the same thing.
make class CustomDueDate
This class can trap and act on any of the events of the control and then perform the appropriate actions you would like. The only code you would need in the form would be something like

private MyDueDate as New CustomDueDate

Private Form_Load()
myDueDate.initialize Me.txtDueDate, Other Parameters
end sub

However, as mentioned if all you want to do is update table data then look at a data macro.

Not that I would do the following as written, but it does what you are asking.
The code in any form is this.

Private CDD As New CustomDueDate
Private Sub Form_Load()
  CDD.Initialize Me.DueDate, Me.Reminder
End Sub

It will update the Reminder field whenever the due date updates.

Option Compare Database
Option Explicit

Private WithEvents m_TextBoxDueDate As TextBox
Private m_TextBoxReminder As TextBox
Public Sub Initialize(TxtDueDate As TextBox, TxtReminder As TextBox)
  Set Me.TextBoxDueDate = TxtDueDate
  Set Me.TextBoxReminder = TxtReminder
  Me.TextBoxDueDate.AfterUpdate = "[Event Procedure]"
End Sub

'****************************************************************************************************************************************************************
'-----------------------------------------------------------------------------------   Properties   -------------------------------------------------------------
'*****************************************************************************************************************************************************************

Public Property Get TextBoxDueDate() As TextBox
    Set TextBoxDueDate = m_TextBoxDueDate
End Property

Public Property Set TextBoxDueDate(ByVal objNewValue As TextBox)
    Set m_TextBoxDueDate = objNewValue
End Property

Public Property Get TextBoxReminder() As TextBox
    Set TextBoxReminder = m_TextBoxReminder
End Property

Public Property Set TextBoxReminder(ByVal objNewValue As TextBox)
    Set m_TextBoxReminder = objNewValue
End Property
'****************************************************************************************************************************************************************
'-----------------------------------------------------------------------------------   Events   -------------------------------------------------------------
'*****************************************************************************************************************************************************************

Private Sub m_TextBoxDueDate_AfterUpdate()
  If IsDate(Me.TextBoxDueDate) Then Me.TextBoxReminder = Me.TextBoxDueDate + 5
End Sub

Again this is a demonstration of the concept, and I am not suggesting I would use a custom class to do something so simple. But lets assume there is a lot more functionality we want to add to this CustomDueDate class.

 

[Edgar_]

You might not require Reminder_Date.

Since Reminder_Date depends on Due_Date, Reminder_Date could be a calculated field or it could be something a form or something else takes care of by looking at Due_Date.

 

[NauticalGent]

Building on what MajP had shared, you may find this helpful:

 

[arnelgp]

you can use Data macro as suggested in post #3 or
you can just make Remider_Date a Calculated field.

you can also dump the Reminder_Date and just use a
Query to create a Calculated Column for the Reminder_Date.

you don't need any VBA just for this simple task.

 

[Pat Hartman]

I have more of a theoretical question today, I'm mostly looking for inspiration on how I might be able to take advantage of the OOP paradigm in the application I'm working on.

Don't. OOP is out of favor. It didn't produce the expected results. There are better methods.

If I bump the due date up 5 days, the reminder date gets bumped up 5 days as well to maintain the distance between them.

That is evidence of a poorly normalized schema. If the reminder date is always a fixed period prior to the due date, then you calculate the reminder date in your query, you don't store it. If the distance between the two dates is not fixed, then perhaps there is a table where it should be stored.

The same subroutine getting called in multiple places isn't the end of the world, but what if in the future there's another form that changes the due date, and another? I would have to continuously remember to add calls to the subroutine or otherwise get inconsistent behavior throughout my application.

There is nothing magical about this that a class would solve. YOU are the only one who knows which behavior to apply and when.

I know there others who never use classes, and some that use them quite a bit. If classes are used in the right way, they can be quite powerful. I would try and go for the simplest solution that you can work with.

So far, MajP is pretty much the only person who posts regularly about classes who actually uses classes correctly. Yes they are powerful but only when the code is actually reusable WITHOUT additional logic. If you have to add logic to the class module to decide on what path to take through the code, you are not using classes correctly. They should be black boxes. They take specific inputs and produce specific results.

As I tell all newcomers to Access - don't start with code. Experienced developers are extremely dangerous as new Access developers because they don't bother to try to figure out the "Access Way", they just write code to attempt to bend Access to their will and end up hating Access in the process. First try to do what you need with queries, property settings, internal VBA functions. Then if you have no option, write code. Write functions for code that is application specific but which needs to be run from multiple forms/procedures. Pass in a form object to allow the function to reference form controls directly. As long as they are named the same, the code needs no additional logic. I will extend that to create a class BUT be absolutely certain that you are creating a class that is actually reusable. If you are not going to use the class outside of the current application, it probably should not be a class, it should be a called function or procedure for simplicity. Do not create a class just to show how clever you are. Use the simples, most easy to understand construct available. Remember, you are using a RAD tool so keep your solution RAD when you can. If you review the classes MagP has created and published for us to use, he's probably covered everything that you would ever need. Some of his classes are legendary

My worst nightmare was having to modify an app written by someone who hated Access but thought OOP was the cat's meow Most classes were one line of code and frequently required nesting as many as 7 levels to get to the actual executable line of code. And this person thought of himself as a "professional". I took two days to get my head around what the app was actually supposed to do. Then I took another 2 days to excise all of the class modules and replace them with embedded code (one line of code does not require a function or class, I don't care how redundant you think it is) or functions/procedures as needed. Luckily the app was not very big or even very complicated. It was the developer who made it complicated and unmaintainable. This was the ONLY app I ever needed to rewrite just to modify. It was worse than anything created by a novice.

I've seen way too many cases where people take VBA functions and "abstract" them which is downright idiotic and shows they don't have a clue what abstraction actually means. Granted, most of the examples on line show the arguments to functions as hard coded. Well of course you won't hard code the arguments. You replace them with variable or form field references. THAT is the only abstraction needed. You don't need a totally new function that takes arg1, arg2, arg3 which you fill first and then call the function that takes arg1, arg2, and arg3 and populates the standard VBA fuction.

 

[MajP]

Don't. OOP is out of favor. It didn't produce the expected results. There are better methods.

That is a pretty grandiose statement. Almost all large scale applications and languages are built as OOP. OOP is definitely not going anywhere soon, but it is be being augmented by other coding paradigms such as functional programming. There are definitely not "better methods." to replace OOP in entirety, but there are better methods to do certain things. For what OOP does well (user interfaces, modularization, encapsulation) there is really no real replacement.

So I think there is some confusion that when working in Access you are not applying OOP constructs. Although VBA may not be fully OOP because it does not really support the tenets of inheritance and polymorphism, it is pretty close. IMO it supports the two most important tenets of abstraction and encapsulation. So instead of "OOP" lets use the term in post #7, Object Based Programming (OBP) so as not to offend the purist.

Everytime you work with a form, report, control or any object in vba you are exercising OBP (OOP light). Example

dim frm as Object
set frm = forms!frmone     ' Polymorphism since you defined as object and subclassed to form. and Encapsulation using a class to hold a form props,  methods
Frm.requery                ' abstraction. Hide the inner workings of the class
msgbox.form.control1.name  ' Composition of child classes inside a class and encapsulation and abstraction

To call a method in a class (lets disregard for now "shared/static" methods) you instantiate an object of that class and then you can call the method that is encapsulated in the class

dim myObject as myCustomClass
myObject.SomeMethod

People do not understand that VBA is OBP/OOP light and cannot figure out that a forms module is a class module. People try to call the method simply by typing the method or get a property by simply typing the property. However that method is encapsulated in that class. You would do the same way you would do with any OOP design by calling it through the instantiated object.

Dim frm as Form
set frm = forms!MyForm
frm.SomeMethodInMyForm

My worst nightmare was having to modify an app written by someone who hated Access but thought OOP was the cat's meow Most classes were one line of code and frequently required nesting as many as 7 levels to get to the actual executable line of code. And this person thought of himself as a "professional". I took two days to get my head around what the app was actually supposed to do. Then I took another 2 days to excise all of the class modules and replace them with embedded code (one line of code does not require a function or class, I don't care how redundant you think it is) or functions/procedures as needed. Luckily the app was not very big or even very complicated. It was the developer who made it complicated and unmaintainable. This was the ONLY app I ever needed to rewrite just to modify. It was worse than anything created by a novice.

That has nothing to do with OOP that is just stupid design and coding. People can do dumb stuff in any construct. When all someone has is a hammer then ...
I am with you on being impatient with people who feel that they need to out smart "Access" and can do a better job by over engineering. They write overly complicated unbound forms when they could have done the same thing in a fraction of the time and code with a bound form. They write complicated custom classes because they do not understand that the form's class is a class and all the same thing in the form class can be done without need for additional custom class (Add custom properties, trap external events, raise custom events).

I think people think that OOP in access means having to write and only use custom classes. I would argue if you never write a custom class you are already doing OOP and you should understand that.

So I think the real question when people ask in "Access should I do OOP", is really "Do I need to create custom Classes". The answer to should you do OOP in Access is absolutely YES. Why, because you are already doing it so you should understand that, even if you never build a custom class.

So do you need to learn to use custom classes? I would say if you do not, you are handicapping yourself. I can show plenty of my apps that could not be done any other way or would be so incredibly complicated not to do it using custom classes. However, at the same time you need to know enough to understand because you have a hammer not everything is a nail. Bad code is bad code.

Most common use for me is building "psuedo user controls". In VBA you cannot create a User Control like you can do is say VB.net. This would allow you to take a group of controls and give them a functionality that can be dropped onto any form. However using a custom class and the principle of composition you can build a psuedo user control that can be used on any form and recreated with minimal code. I have lots of these that allows me to create functionality in seconds what takes others minutes/hours.

Secondly you can better organize and encapsulate your code. I see people with code that is just a mess with lots of tightly coupled functions, global variables, temp vars, etc. This can be made far simpler with a good custom class.

Third you can centralize event listening to handle multiple objects.

Fourth is reusability and composition of objects. Build once use many times and build in pieces.

 

[tvanstiphout]

I like using classes in Access, in a number of ways.
* Static classes such as clsErrorHandler in Northwind 2 Dev Edition (NW2), to further encapsulate error handler functions.
* Form subclassing, so we can have common functionality (responding to certain common events) implemented once, and don't even have to create those event procedures in the next form, as long as it is subclassed as well (a line or two in Form_Open and Form_Close). In my case some of the common functionality includes highlighting required fields if user tries to save a partial record (NW2 has simplified highlighting code, but not the subclassing).

Just for fun I tried implementing NW2 with "OOP to the max" using ideas from rubberduckvba.blog, and ran into its limitations wrt Events.
"Object or class does not support the set of events - Visual Basic | Microsoft Learn" says this:
For example, you wanted to sink the events of an object, then create another object that Implements the first object. Although you might think you could sink the events from the implemented object, this is not always the case. Implements only implements an interface for methods and properties.
So I gave up on this project. If I pick it up again, I will perhaps use twinBasic, or C#.

 

[Pat Hartman]

So I think there is some confusion that when working in Access you are not applying OOP constructs.

The Access executable provides objects that the Access developer uses to create his custom versions of those objects. In other real OOP environments, you start with a blank slate. So, if you wanted to build "Access" you would have to write the code to create a form object. You would have to define sub objects like controls. Then you define methods and procedures for everything and hooks (events) where the code could be customized, etc. So, out of the box, Access gives you an OOP framework. They have provided the basics. In theory, you can build an entire application without writing a single line of code. In reality, we always need custom code at a minimum to validate data before we allow it to be saved. Then there are other things that we might want to add on. Many people don't like the tiny navigation bar used by forms/reports so they prefer to build their own. This is ideal as a class module because the behavior will be 100% the same regardless of the application. So, this code can be ported from one form to another and from one application to another without changing code. Your search while you type listbox is another good example. It makes absolutely no difference what the application does or what form you use the class on, it can be implemented with NO code changes. An error handler is another potential case for an actual Class. You provide the error message and some indication of where the error happened and the class module creates a log and displays a message and perhaps sends an email to an admin to report the issue if it is urgent. This could just as easily be implemented as a function. I'm sure we can all think of other functionality where a class would be a viable option.

Many things we do are abstracted by using tables to provide variables for different situations. Code isn't necessary. The code is simple. Look up the relevant record and perform a calculation. Works fine as a procedure or function. Doesn't need to be a class and will almost certainly never occur again in any other application you build but similar things might. Should you try to make a class? Unless you've actually implemented the function straight up multiple times, you probably don't even know enough to make it generic. Maybe the third time around you will have an understanding of what arguments you need and whether or not the code is actually generic once you have provided a fixed set of inputs. I have a couple of these generalized mini-apps. Things like code table maintenance. I always seem to have a bunch of simple value lists used for combos/listboxes and many of them can be added/updated although not deleted by users. If the values in the list don't need to trigger different code paths, then I might as well let the user have control over adding new values rather than making them request a version update to add a new value to a list or change its name. I don't make this a class, I make it Access forms/reports/tables which are themselves classes. They are simply customized for the task of managing a specific type of list. I keep them in a database and import all the objects when I need them. They take on the color palette and fonts of the main app due to the wonder of themes and they're good to go.

The OP wants to build classes that shouldn't be classes and probably shouldn't even be functions or procedures because they are custom to each situation. The point here is that not everything should be a class and your objective should not be to always create a class before you write a line of code. You need to understand what "generic" actually means and it is not creating a class to always update one date based on the change to a different date, especially since you probably shouldn't be storing both of these dates anyway.

Classes are not inherently better than more standard VBA code. They are not worse either. However, they are constantly misused. The key is knowing what will be reused and therefor what could/should be made into a class.

 

[Edgar_]

In my opinion, nobody learns classes by not writing classes.

To understand what classes do, one must actively write them regardless of others' views on their purpose. Additionally, classes aren't always designed with reuse across projects in mind, if instancing something makes sense, then you do that.

 

[Uncle Gizmo]

"Can I have some examples from fellow Access programmers of how you've utilized classes and OOP in your databases to write more effective and easy to maintain code? Is there even any such thing as coding using the OOP paradigm in Access?"

To give you a different perspective, I built a class module for handling pop-up forms...

At the time I created the videos I was a complete beginner and I'm still not much better now!!!

I did a series of videos on it on YouTube which you can find in this playlist

Object Oriented - Nifty Access

Object Oriented - Nifty Access

For about 10 years now, on and off, mostly off! I've been looking at building a Class Module, to get some experience in Class's. I built the CallCalled Class...

www.youtube.com

As I perfected the class module it got better and better and this is my latest version of it:-

Latest "Call Called" Class Module

CallCalled Class Module - Nifty Access

CallCalled Class Module I will be adding information about my "CallCalled" Class Module here, as it becomes available. The most recent example of it is on Access World Forums here:-VBA to reuse data entry popup form Class Module - Overview Class Module - Overview Video 1 (01:09) You can see how...

niftyaccess.com

 

[Uncle Gizmo]

Here's a look at another Class Module Chatty helped me Create which does away with the need to have code stubs in the form!

Dynamic/reusable forms

New to this forum, triggered by a thread, but alas I cannot find that thread. So I will sketch my situation. Since long I work on generalization of code to make programs more powerful and robust. Code must be as structured as normalized data. This has resulted in automation of many of the...

www.access-programmers.co.uk

 

[moke123]

I struggled to wrap my head around classes for a long time until MajP posted some code which somehow made it make sense. I owe him props for that. Ever since I always try converting things to classes just for fun and as a learning Tool. The things you learn along the way are invaluable. I would recommend it to anyone.

 

[MarkK]

I'm curious of there's some clever way to structure my codebase to allow for this kind of thing.

I write a service class for almost any information domain in an application. The service class takes responsibility for all business logic in respect to a particular domain. Any and all business logic--exactly like the kind of thing you are talking about, where if one date is advanced, a second dependent date must also be advanced--is encapsulated by the service.

The advantages of writing this as a class are twofold, 1) the object exposes its members via intellisense, so finding out what it does 6 months from now is easy, and 2) you don't pollute the global namespace with public method calls as you would if you exposed the same functionality via standard modules.

The advantages of writing it at all is that it centralizes and organizes all the logic you might need to universally apply to your business objects.

How. Expose your services via a provider, which is just another service, but it exposes other services, again available via intellisense. So if you have a service provider like this in a standard module...

Private svc_ As cServiceProvider

Public Property Get svc() As cServiceProvider
    If svc_ Is Nothing Then Set svc_ = New cServiceProvider
    Set svc = svc_
End Property

... and the service provider exposes services, including a cOrderService...

Private svcOrder_ As cOrderService

Public Property Get Order() As cOrderService
    If svcOrder_ Is Nothing Then Set svcOrder_ = New cOrderService
    Set Order = svcOrder_
End Property

Then, if cOrderService exposes methods like...

Public Sub UpdateDueDate_EndNextMonth(OrderID As Long)
    UpdateDueDate DateSerial(Year(Date), Month(Date) + 2, 0), OrderID
End Sub

Public Sub UpdateDueDate(NewDate As Date, OrderID As Long)
    UpdateField "ReminderDate", NewDate - 5, OrderID
    UpdateField "DueDate", NewDate, OrderID
End Sub

Private Sub UpdateField(Field As String, Value, OrderID As Long)
    ' perform the database operation
End Sub

Finally, in your UI you can write...

Private Sub cmdSetDueNextMonthEnd_Click()
    svc.Order.UpdateDueDate_EndNextMonth Me.OrderID
End Sub

This is a way you can use classes to organize all your business logic. The provider exposes domain services. The service exposes domain methods. And then the magic happens when business rules change--all you have to do is update your service methods. UI consumers don't know or care.

This is how you can build a complex scalable systems.

 

[MajP]

Many things we do are abstracted by using tables to provide variables for different situations. Code isn't necessary. The code is simple. Look up the relevant record and perform a calculation. Works fine as a procedure or function. Doesn't need to be a class and will almost certainly never occur again in any other application you build but similar things might. Should you try to make a class? Unless you've actually implemented the function straight up multiple times, you probably don't even know enough to make it generic. Maybe the third time around you will have an understanding of what arguments you need and whether or not the code is actually generic once you have provided a fixed set of inputs. I have a couple of these generalized mini-apps. Things like code table maintenance. I always seem to have a bunch of simple value lists used for combos/listboxes and many of them can be added/updated although not deleted by users. If the values in the list don't need to trigger different code paths, then I might as well let the user have control over adding new values rather than making them request a version update to add a new value to a list or change its name. I don't make this a class, I make it Access forms/reports/tables which are themselves classes. They are simply customized for the task of managing a specific type of list. I keep them in a database and import all the objects when I need them. They take on the color palette and fonts of the main app due to the wonder of themes and they're good to go.

I am not sure if we are saying the same thing or not. But next to Access forms, reports, and controls the most used objects and in my opinion and great example of OOP/OBP is the DAO and ADO library. Here again if an Access developer is not well versed in OOP they are at a disadvantage working with these object libraries. Probably no better place is the principle of Composition in OOP on display then here.

In other real OOP environments, you start with a blank slate. So, if you wanted to build "Access" you would have to write the code to create a form object. You would have to define sub objects like controls. Then you define methods and procedures for everything and hooks (events) where the code could be customized, etc.

I do not understand that statement since it is just not true. Have you built database front ends in any other language? Pick VB.net for example, which is now a full OOP language as far as I know. All the bound controls, forms, connectors, providers etc exist. Building a form and adding controls is pretty much just like doing it in Access. Just like access you can bind a form to a source and then drop controls and bind them to fields.
In fact to teach myself Visual Studio I rebuilt Northwind front end with an Access BE. Sure the learning curve is steep, it is not RAD, and there are things that a harder to do right out of the box. However there are also things that you only wish you could do in Access.

 

[MarkK]

Don't. OOP is out of favor. It didn't produce the expected results. There are better methods.

This is a statement by a person about herself. This is not a statement about OOP.

Everything you do as a programmer is underpinned by OOP. You may not write classes, but the context in which you write code and every resource your code consumes is a class, and is exposed by a class. Any action you then take that broadens your understanding of what classes are, and how you might use them, is valuable.

 

[SparklySpartan]

First off, I appreciate all the responses!

I'm glad that a variety of views on this subject ended up being posted here in response to my kind of impulsive, not super well thought out question.

To all of you who pointed out that this is a very simple problem to solve and does not deserve a class, yeah, that's fair. The example I gave in my question was pretty silly, but it did get me wondering. I'd imagine there are more complex variations of problems like this one where people have needed to implement some centralized logic as well as use classes in other ways to make their code better. Haven't dived into MajP's or UncleGizmos examples yet, but I'm looking forward to.

Also, I had no idea data macros were a thing. This might just be the cardinal sin, but I totally skipped straight to VBA in my solution making. I came from an Excel development background so all I did before diving in was find out a bit about how forms, tables, and SQL work and dove straight into development. Pat Hartman made a decent criticism of rascals like myself doing just that. I should not be jumping to the most complex solution before finding out the way it's done "Access-style"

To all of you who pointed out that I shouldn't even be storing both dates in the first place: Oh my goodness... you are so right. Now that I think about it. I'm not sure why I thought it would be necessary to store both. Just storing the due date and then the amount of days before instead of storing both dates removes this potential complexity entirely. Instead of storing the reminder date I'll just calculate it every time I need it. That way, there's no weirdness of changing one field when you change another anyways. I'm perfectly happy to be the brunt of the joke here, especially because it's increasing my learning and hopefully the learning of others as well, and I totally just avoided shooting myself in the foot with bad database design, so thanks!

The original issue I raised has been erased now, which I appreciate. The main reason I asked the question was to see how people would talk about using classes in general. I wanted to know how others used this tool to see how I could be using it in more of a general, and this simple issue is what originally lead me down that thought process. I'll be diving into the examples of from y'all who do use classes to see where I might benefit from them. I'll try not to overdue it, though.

Thanks again!