[AccessD] Example of Class Module usage needed

Jim Dettman jimdettman at verizon.net
Mon Sep 26 10:22:38 CDT 2016


Arthur,

<<Early on in the history of O-O, there was the concept of multiple
inheritance (that is, class C inherits from both class A and B). >>

 Wasn't Eiffel like that (and for your other question, don't know if it's still in use or not)?  Don't remember off-hand....that was a long, long time ago<g>.

 I would agree too that top down has some fundamental problems.  That's why OOP and Classes are not all their cracked up to be either. You really can get into some messy situations and end up with a lot of work as a result in re-designing a hierarchy.

 Interesting thought on promoting attributes...there are a lot of nuances to OOP that you really can't appreciate until you do it.  I've been away from it for a bit now (back to Access!), but it was fun to dig into it at the time.

Jim. 

-----Original Message-----
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Monday, September 26, 2016 09:32 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Example of Class Module usage needed

Jim et. al.

There is a funny thing about classes and inheritance. In the history of
evolutionary thought, species and phyla were created (discovered) in a
bottom-up fashion; only by comparing apparently different species did
Darwin and the rest of us in his wake realize that they shared a common
ancestor. In addition, there have been many cases wherein a given species
was originally thought to belong to one ancestral line, and only later was
discovered to belong to another. This has even applied to assignment to a
phylum (c.f. Stephen J. Gould's *The Burgess Shale*).

The current top-down orientation of O-O development is radically different
than what happened in the biological world. The O-O model embodies a
God-like perspective (the ultimate case of top-down design).

What does this have to do with O-O? Simply this: there ought to be a way to
promote attributes and methods, rather than or in addition to inheritance.
In practice, this would mean something like this:

I design two classes, apparently quite different, but as I play with them I
begin to realize that they share some subtle things in common that I hadn't
realized when designing them as separate classes. So now I design a
superclass, and promote the attributes and methods they share upward, then
modify the original two classes to inherit from the superclass.

Of course this can be done manually, by creating the superclass and then
visiting each of the original classes and adding the *Inherits* keyword to
each definition. But I was thinking of a more graphic view of the
hierarchy, with Drag and Drop, so that I could accomplish this visually:
just Drag an attribute or method from one of the "lower" classes up the
chain to the superclass. That would be really cool.

Early on in the history of O-O, there was the concept of multiple
inheritance (that is, class C inherits from both class A and B). I think
that this came to be seen as a bad idea, and was abandoned by most or all
the languages that supported it. I don't if any language still supports it.
Do you?

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