object oriented programming

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
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?
Click to expand...
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 <--
 
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
Click to expand...

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.
 
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.
 
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.
Click to expand...

VBA does polymorphism via interfaces. Whether this is 'true OOP'
depends on your point of view but "no mechanisms for polymorphism"
sounds like a misstatement.

See:

http://msdn.microsoft.com/library/d...l/vbconhowvisualbasicprovidespolymorphism.asp

How Visual Basic Provides Polymorphism

"Visual Basic doesn't use inheritance to provide polymorphism. Visual
Basic provides polymorphism through multiple ActiveX interfaces. In
the Component Object Model (COM) that forms the infrastructure of the
ActiveX specification, multiple interfaces allow systems of software
components to evolve without breaking existing code."

Jamie.

--
 
VBA does polymorphism via interfaces.
Click to expand...

FWIW I use interfaces in VBA and they work well e.g. CBaseTable and
CView both implement ITable, IColumnParent is additionally implemented
by IConstraint etc. Useful when you want to write strongly-typed early-
bound code (who doesn't <g>?)

I don't write VBA code in the Access user interface but I can see why
those who do may be reluctant to embrace OOP e.g. Access is for RAD
(R=Rapid) but OOP in VBA requires more work; writing code for coders
makes more sense in a team delivering compiled components within
release cycles whereas Access projects are often 'one coder, one
customer, one component, one version' affairs etc.

Jamie.

--
 
Back
Top