I think it depends on how big of an application you're making, small/simple things don't really need it, and I don't think there is a real need for it in Access that you can't just use a public function for. But I've been learning a lot about javascript/react and the likes to build a web application for the last 6 months and one thing I've heard and noticed is when you get to around 300+ lines of code in the same page/form/function, it starts to turn into spaghetti, OOP seems to help with that drastically.

I still would love to learn how to use it with access.

You will. I'll be covering it... More because it's "neat" than a necessity. You can do some cool things with it... I've just never NEEDED it.

I'm an old school programmer, and over the years I've found the need to pass a variety of parameters to a public SUBROUTINE to make it more useful in a variety of situations.  Often the results of the sub are passed back for further processing after the calling statement.  I would be very interested to see how well that might work in OOP.

That's actually much easier because you can pass an entire object as a parameter.

@Richard Let's take something I'm working on at the moment. I need to format address in a variety of ways. For example, in some countries, the postal service may require a certain format, but other private delivery companies may require a different format. Sometimes I want the Entity's name added to the label, and other times not, it depends on the address. The "objects" I may need to pass are the Address and the Entity data (name which may depend on what kind of Entity it is). And in all cases the delivery service. Bundle all that up to get a properly formatted address returned in an array, for each line. The actual printing program might print a standard label, or need to take array elements and place them in certain positions on the waybill. Addresses are in a table, and there is a separate postal code table, all of which consider the country that the address is in. We don't allow "ad hock" address entry in things like an order table.

Now consider this interesting situation. I want to send something to Richard. Richard works at another Entity: Amicron. So, I have an address for Amicron, but I want to send the package to Richard at Amicron. In this case I have two Entities and one address for Amicron. I could use the same address record for Amicron, and make it a duplicate for Richard (in the one-to-many table). But the delivery service and your work want to see both "Attn: Richard" and Amicron on the label, or it won't be delivered or accepted.

To get this all done may require a dozen parameters that aren't in the Entity or Address objects. I did this all once before (not in VBA), many years ago; it was a huge subroutine. I've read some OOP references, but they seem tackle much simpler and straight forward issues.