[AccessD] Class costs & benefits

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 (harakiri)...

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
> 
> 

<<< tail trimmed >>>