• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1892
  • Last Modified:

Mapping Object Oriented Programming concepts to VBA

I'm maintaining a MS Access 2000 application. I'm accustomed to languages (e.g. Python) that provide thorough Object Oriented Programming support, and I struggle with the very limited Object Oriented Programming support in VBA. I'm wondering whether you have any suggestions regarding mapping Object Oriented Programming concepts to VBA. It seems to me that there is so much that I just can't do, and a little that I can do that requries writing much more code than I'd use in Python.

It amazes me that MS has provided such a limited oop model!
0
ramrom
Asked:
ramrom
  • 3
  • 2
2 Solutions
 
Arthur_WoodCommented:
VBA supports some OO concepts, and not others.

with VBA you can create your own classes, and you can create objects from those classes.  However, VBA does NOT support Inheritance, and does not truly support 'polymorphism' in the classical meaning of the term as used in OO languages such as C++, or .NET.

VBA classes do support encapsulation, and abstraction.

VBA was never designed, nor intended to be a OO language.  If you try to force pure OO concepts onto VBA, you will fail in the same way the cowboys attempting to use Ostriches to herd cows will fail.  Yes, you can strap a saddle on the back of an ostrich, and yes, you can put a set of reins on an ostrich - but that does not make the poor ostrich any type of cow-pony.

AW
0
 
GRayLCommented:
That was a bill-full!
0
 
Arthur_WoodCommented:
oh, and by the way, just because you can't make an ostrich into a cow-pony, does not make the ostrich any less valuable as a bird, and kids still love to see them at the zoo.  Access and VBA have their place in the IT marketplace, and just because VBA is not (and was never advertised as) an OO language, does not make it any less viable as a programming environment.

AW
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Arthur_WoodCommented:
Also, remember that Access and VBA have been around for a LONG time - I started using Access (Access 2) back in 1990, with AccessBasic - (the earlier version of what was to grow into VBA) - long before OO concepts were being tossed around freely - oh sure, there might have been SmallTalk, and C++, but those languages were totally beyond the range of experience or use of the typical Access user.

AccessBasic was based on BASIC, as was Visual Basic - and Visual Basic did not gain even the rudiments of OO concepts until VB4, in about 1994 or 1995.  So the history of AccessBasic and VBA would preclude almost any implementation of full OO concepts.  Just look at the howling and snarling and loud gnashing of teeth that accompanied the introduction of TRUE Obejct Oriented Concepts - the whole nine-yards - with the release of Visual Studio.NET and the accompanying 'culture shock' that hit the casual VB users like a ton of bricks - and they saw themselves as true 'programmers' - Access users rarely see themselves as Programmers - in the strict sense of the word.  Trying to get Access 'developers' to learn and comprehend the principles of OO development would fail dismally, and with it would go one of the most successful Desktop Database tools ever created.

AW

AW
0
 
harfangCommented:
Well, I want to comment on this.

Wile VB isn't an OOP language, it must be said that it's clearly OLO. Whenever I teach VBA, I clearly distinguish between the "scripting language" or "interpreted language" in which we write our code, and the very powerful objects that are at our dispsal. And VB is clearly "object library oriented" because you can write those beautiful and incredibly succinct lines of code _using_ objects.

Before you start to create your own objects, study in detail what you can do with the existing: Recordsets, Fields, Forms, Controls, Connections, VBComponents, Errors, not to mention all the available ActiveX components. Integrate this with the event-driven paradigm, and VB becomes a good platform. For small applications, for quickly changing applications, for prototyping and for teaching.

But perhaps the best question is: what is it exactly that you are missing? If you are looking to define a new data type, if you want to overload an operator, or if you want to modify an existing class method, then you need to look elsewhere. But if you want to create an object that contains an encapsulated form and a recordset, a set of classes to automate HTML exports, or create a new spinner button control, you can do that in VB, but perhaps not exactly in the way you are used to.

Another problem you are facing is that Access is a three-headed beast. Access per se is merely a decent but far from perfect database and GUI design platform, and a runtime library. It interfaces with VB mainly through exposed user and database events. The database engine also interacts with VB, by a shared functions library and by several object libraries. So that neither the interface nor the data are really part of VB. How can you have any serious OO support in a language that controls neither?

So again, tell us one or two of the things you are struggling with. We might stop the arguing and start being useful ;)

Cheers!
(°v°)
0
 
GRayLCommented:
Well said.
0

Featured Post

 [eBook] Windows Nano Server

Download this FREE eBook and learn all you need to get started with Windows Nano Server, including deployment options, remote management
and troubleshooting tips and tricks

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now