[AccessD] Class costs & benefits

Salakhetdinov Shamil mcp2004 at mail.ru
Thu Feb 26 04:39:06 CST 2009


Hi John,

<<<
inheritance is a double edged sword.
>>>
Currently I'd suppose that custom classes without inheritance is a double edged samurai's sword and a Tantō blade for final seppuku (harachiri)...

I'd also find sometimes good use of multiple inheritance even in business applications.

I suppose that C#/VB.NET (.NET CLR) not having multiple inheritance is because of some technical limitations MS weren't able to overcome by this time. I'd guess they may introduce multiple inheritance in C#/VB.NET in the future as C#/VB.NET getting new and new language features with every new .NET Framework version release.

MS not giving us VB6/VBA developers custom classes inheritance and some other advanced OOP features were I suppose because of technical limitations, which are still existing in VBA. Here is one example on how complicated VBA code with custom classes could become because of absence of inheritance:

http://smsconsulting.spb.ru/patterns/labs/ObserverPatternLab.htm

I'm grateful to MS and MS Access because they allowed me to get a lot of business application experience and business contacts and this great AccessD community during the last 15 years, but I sometimes "hate" MS and MS Access VBA because they forced me (yes, stupid me, of course) to spend too much time as I see now trying to use VB6/VBA for what they were not designed for: I mean building advanced custom classes/object models/hierarchies/gropings/aggregates...

I see you're aware of that VBA limitations - I'd just add byside note to your lectures for other developers who are only starting with custom classes for those developers to not try to "go over the edges" using VBA (as in referred above Observer Pattern sample) - they better switch to VB.NET/C# - the latter would be less time consuming investment as my and others experience shows, and almost no pain switch and no reason to use seppuku beaten by VBA limitations and getting failed projects and lost profits and customers....

Sorry, if I'm missing the point that awareness of VBA limitations' "blues" is implied in your lecture notes, and everybody but me accepting your lectures in this context...

I'd also note that my experience by just using rather simple VBA custom classes but many (hundreds custom classes modules) in one project (with library projects) and with intensive use of interface inheritance (Implements) always sooner or later resulted with my work getting stuck in GPFs both in MS Access VBA and MS Excel VBA - that were Access/Excel 2003 when I switched to mainly .NET development (when I tested hundreds of custom classes with (set of related) VBA project(s) without Implements that worked OK (I remember I tested Access 97 with FE with 40+ library projects - that worked OK but there was no Implements there yet)).

Finally: I'm in agreement that custom classes in VBA are more of good than evil but do not force beginners to get trapped by them in this limited VBA programming world - advise and let them go to the open (air) world of VB.NET/C# programming as soon as they get comfortable with faily simple programming with custom classes in VBA...

Thank you.

--
Shamil

-----Original Message-----
From: jwcolby <jwcolby at colbyconsulting.com>
To: Access Developers discussion and problem solving<accessd at databaseadvisors.com>
Date: Wed, 25 Feb 2009 17:57:29 -0500
Subject: Re: [AccessD] Class costs & benefits

> William,
> 
> AFAIK multiple inheritance is not possible in .Net either right?
> 
> So yes, inheritance is a really cool feature, and it does not exist in Access.
> 
> OTOH, even in .Net there are things that you want to program that don't inherit from anything. 
> Business class objects come to mind.
> 
> I'll tell you a little story.
> 
> When I was in Mexico I was worked on a vending machine project, broken into three parts.  There was 
> a database in a handheld computer, written in Foxpro for DOS (no inheritance).  There was a database 
> on the desktop written in FoxPro for Windows which had inheritance, and there was the vending 
> machine itself (my part) written in C running on a ZWorld z80 based uC.  The HH code was written and 
> debugged.  The vending machine code was written and debugged.  The desktop db was hopelessly bogged 
> down in discussions on what should be inheriting what base stuff, what should be inheriting from the 
> stuff that they managed to write etc.  It was fascinating to sit at the edges of and watch.
> 
> Now... this was mid 90s and I guess that the inheritance thing was new to these guys but the point 
> remains that inheritance is a double edged sword.  Once you understand and can correctly and quickly 
> make such choices, it can be very powerful.  Until that point you can flounder around a lot...
> 
> I do agree that the .Net framework is one of the most powerful frameworks I have ever seen.  Nothing 
> short of awesome IMHO.
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> 
> William Hindman wrote:
> > ...ok ...a basic view ...the real value comes when you can inherit from more 
> > than one object and you can pick and choose what you inherit ...within 
> > reason, you can build practically anything without having to start from 
> > scratch ...VS gives you some basic tools, a grid for instance ...and you can 
> > go a long time before it dawns on you that you don't have to accept that 
> > basic grid ...you can reach back in the object hierarchy and build a grid 
> > that does what YOU need ...a treeview with a grid node for instance ...all 
> > without having to lay out bucks for third party tools that only do half of 
> > what you wanted.
> > 
> > ...to me, that's the real value of working with dot net ...there is sooooo 
> > much built in high level stuff that lets you easily build low level custom 
> > objects for your apps ...and sooooooo many blogs out there with guys doing 
> > highly creative things that its nigh impossible to keep up.
> > 
> > William
> > 
> > --------------------------------------------------
> > From: "jwcolby" <jwcolby at colbyconsulting.com>
> > Sent: Wednesday, February 25, 2009 4:14 PM
> > To: "Access Developers discussion and problem solving" 
> > <accessd at databaseadvisors.com>
> > Subject: Re: [AccessD] Class costs & benefits
> > 
> >> The simplest illustration is to say that inheritance is the ability to 
> >> define your own object as
> >> starting from something already in existence.
> >>
> >> Inheritance in the programming world mimics inheritance in the genetic 
> >> world except that in most
> >> languages you are only allowed to inherit properties from a single parent.
> >>
> >> So.  I am my dad.  I get everything my dad has, his eyes, his height, his 
> >> race, his ...
> >>
> >> I add to what I inherited.
> >>
> >> I add a bunch of extra pounds.  I add the experience of living in Mexico 
> >> for five years.  I add the
> >> knowledge of building computers.
> >>
> >> In programming.  I inherit a text control.  I add code to check my control 
> >> source to see what data
> >> type it is.  I then add new method to make my display format depend on the 
> >> data type I am bound to.
> >>
> >> I have all of the normal properties of a text box.  I can generate all of 
> >> the events that the text
> >> box generated.  But I have additional code to check my data type and 
> >> format myself differently
> >> depending on the data type.  And other useful things.
> >>
> >> That in a nutshell is inheritance.
> >>
> >> Access does not have inheritance.  That doesn't Accesses classes useless 
> >> however.  A class is far
> >> more than the ability to inherit another object, even in languages where 
> >> inheritance is possible.
> >>
> >> John W. Colby
> >> www.ColbyConsulting.com
> >>
> >>
> >> Rocky Smolin at Beach Access Software wrote:
> >>> "I will promise to treat every opinion as valid and not go into rant 
> >>> mode.
> >>> ;)" Gonna be a pretty dull thread.
> >>>
> >>> For those of who don't know, can you define inheritance?
> >>>
> >>>
> >>> Rocky Smolin
> >>> Beach Access Software
> >>> 858-259-4334
> >>> www.e-z-mrp.com
> >>> www.bchacc.com
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: accessd-bounces at databaseadvisors.com
> >>> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> >>> Sent: Wednesday, February 25, 2009 7:48 AM
> >>> To: Access Developers discussion and problem solving
> >>> Subject: [AccessD] Class costs & benefits
> >>>
> >>>  From Rocky's email I thought that perhaps a thread on what the costs and
> >>> benefits are for classes.
> >>>
> >>> Jim made a statement that he felt that "Access has no implementation
> >>> inheritance and since inheritance really is the whole point of using
> >>> classes, I think they are more or less a waste in Access".
> >>>
> >>> So what are your feelings and opinions about classes?
> >>>
> >>> I will promise to treat every opinion as valid and not go into rant mode.
> >>> ;)
> >>>
> >>> In fact I will promise to not respond to any message unless the author
> >>> specifically asks me to for some reason.
> >>>
> >>> --
> >>> John W. Colby
> >>> www.ColbyConsulting.com
> >>> --
> >>> AccessD mailing list
> >>> AccessD at databaseadvisors.com
> >>> http://databaseadvisors.com/mailman/listinfo/accessd
> >>> Website: http://www.databaseadvisors.com
> >>>
> >> -- 
> >> AccessD mailing list
> >> AccessD at databaseadvisors.com
> >> http://databaseadvisors.com/mailman/listinfo/accessd
> >> Website: http://www.databaseadvisors.com
> >>
> > 
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 




More information about the AccessD mailing list