[AccessD] Log Class part 1B

JWColby jwcolby at colbyconsulting.com
Sun Jan 7 20:48:15 CST 2007


Jim,

There certainly is no panacea in software, and I make no claim that my
classes and the framework built from it solves every problem known to man.
I do claim that doing things this way makes my development waaaay faster and
more powerful than the old "functions in a library" method, or the older
"functions in modules in the application" method. 

VBA's objects cannot even claim to be true OOP in the sense that most
programmers of more powerful languages think of it.  Without inheritance,
the whole concept is crippled, however that does not mean that classes and
objects in VBA are useless, far from it.  

It is true that Microsoft's office objects do not allow you inherit them,
their properties and methods.  However you can use classes to wrap them up.
Given that classes can sink events, and source their own events, you can
wrap any object up in a class and "extend" the object's functionality with
your own ideas.  True, I have no idea how a combo object works inside, it is
about as "black box" as you can get, but I have a pretty fair understanding
of what properties it has, what I can do with those properties, what events
this object will source, and why the events happen.  That is a lot of
information and a lot of power.  

I do not see any reason to just throw up my hands and say "it's all useless
anyway so why bother".  I do a LOT of things that very few if any of you
guys do, but perhaps that is only because you throw up you hands... Or
perhaps it is because you just haven't yet "seen the light".  THAT is why I
keep preaching the concepts because what is possible is so much more than
what I see being done by most of the people on this list.  

There is a saying out there "we all stand on the shoulders of giants" and I
stood on Shamil's shoulders a long time before I "got it".  Shamil has
mostly moved on to other things I think but I finally started to see the
power, and I am available to show anyone who wants to know this stuff what
is possible.  I am certainly no "giant", but I do think I have taken what I
have learned from Shamil and moved it to a point where I can actually use it
to get real work done, much more quickly than without using these concepts.

Trying to discuss true OOP and all its intricacies is an exercise in
futility when using VBA as the language.  It is truly a "who cares, we can't
do that" kind of thing, but that hardly means "we can't do anything".

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Dettman
Sent: Sunday, January 07, 2007 7:02 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Log Class part 1B

John,

<<Write once, use forever, you applications become consistent throughout
(and EXTREMELY powerful).  But it is not the application providing the
power, it is your framework.>>

  Yeah it sounds good, but you haven't told them about the problem with
composite classes<g>.  This is where OOP just falls flat on it's face.

   After programming with VFP for a few years, I realized I basically had
the same problems as before except that things were a heck of a lot more
complex to figure out.

  Up to that point, I had developed methods (calling standard procedures and
changing code on the fly) to work in non-OOP  languages that gave me the
ability to do things like you are discussing.

  The promise of OOP is that you define it once and it works everywhere.
But when you start getting into composite classes, you find once again that
you have the same code in a lot of different places and are almost back to
square one.  Also with OOP you spend a lot of time figuring out the state of
things because you don't know what other routines may have done.  Since your
not supposed to look inside the box, you can never be sure of anything when
your within an object.  It also requires heavy time up front to properly
develop your classes and interfaces and the class hierarchy.  Screw up with
those and you'll be rewriting a lot.

  OOP does have it's place and it can be powerful and flexible, but you need
to go into it with your eyes open.  It's not the pancrea for programming
problems that everyone believes.  Think about how long OOP has been around;
why is there not more of it?  If it was really that great it should have
flooded the development community by now, yet here we are almost 30 years
later still using non-OOP languages.

  I think there is nothing wrong with using objects simply as a means of
simplifying data structures, but using an object orientated language is not
all it's cracked up to be.

Jim.




More information about the AccessD mailing list