object oriented programming

[George]

Hi to all,

I would like to redesign a rather complex access application using objected
oriented techniques. I find the advice on msdn rather meager. Could someone
suggest a good book on oop techniques WITH RESPECT TO ACCESS AND VBA or maybe
a site were a could find practical examples of such databeses?

thanks in advance, george

 

[Stefan Hoffmann]

hi George,

I would like to redesign a rather complex access application using objected
oriented techniques. I find the advice on msdn rather meager. Could someone
suggest a good book on oop techniques WITH RESPECT TO ACCESS AND VBA or maybe
a site were a could find practical examples of such databeses?

Not directly OO. But the first thing you have to do:

Confirm the correctnes of your Entity-Relationship model.


If it is proven correcect:

Derive a completly normalized (1NF-5NF, BCNF, DKNF) database schema
from it.


http://safari.oreilly.com/1592007236/ch10

and take a look at Microsoft Press.


mfG
--> stefan <--

 

[Bob Hairgrove]

Hi to all,

I would like to redesign a rather complex access application using objected
oriented techniques. I find the advice on msdn rather meager. Could someone
suggest a good book on oop techniques WITH RESPECT TO ACCESS AND VBA or maybe
a site were a could find practical examples of such databeses?

thanks in advance, george

VBA is not really an object-oriented language because it has no mechanisms for
implementing inheritance nor for polymorphism. In Access VBA, you can work with
objects (variables of built-in or user-defined object types as well as class
modules) which can contain other objects, but that is not true OOP.

Class modules are great for organizing your code into logical entities, and you
can achieve a great deal of information hiding with them (which is part of good
OOP style). They also provide routines for initialization and destructionwhich
can come in handy.

As someone else pointed out, it is much more important to ensure that your data
model is sound. You are far better off sticking to functions, procedures and SQL
than thinking that you must somehow do everything "the object-oriented" way.

I would like to add that the most important thing you can (and should) do, is to
make sure that everything in your application is properly documented.

 

[Albert D. Kallal]

As others said, using a OO approach in ms-access don't help a lot.

however, you can create class objects, so you do have some of the OO
approaches available.

Here is an article of mine on *WHEN* to consider using objects.

http://www.members.shaw.ca/AlbertKallal/Articles/WhyClass.html

The above should give you some ideas. Creating a object to just edit a
customer rocrd is a waste of time, and will not yeild any beneifts.

When your code beings to get complex, and you have to maniaple a complex
data strucle with lots of code..then using ojects starts to make sense.