Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Class inheritance versus Object (run-time) inheritance
Message
 
 
To
09/07/1999 20:01:38
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00238626
Message ID:
00239745
Views:
13
David,

>So composition is what happens when I build a Form which contains a typical complement of controls and then I save it as a class ?

Yes, although it doesn't have to be saved as a class.

>Now that I know that composition is not what I thought it was, it still leaves my original question open as to whether generalized OOP considers the concept of inheritance through containership rather than through class. At first blush, it seems like it would really be powerful to be able to do this, although I understand that it creates all sorts of new problems and conflicts with conventional class inheritance.

You don't have inheritance through containership. Inheritance is only from the class to it's BaseClass along the ParentClass tree.

Any contained object can use the services it's container supplies. For example from a method I can call this.parent.SomeMethod() the parent container can process the request, maybe even pass the message on to it's .parent. This does mean that the object in question can only be put into some container that has a SomeMethod method. This may or may not be a serious design issue for you.

>The reason this question arose in my mind is because I realized, after creating my first form (which was the one you coached me on, BTW) that I wanted every control in the form to use the same error processing method. My first naive thought was to define a custom error event method for my form and then have it magically become the error event method of its contained controls...but of course, inheritance doesn't work that way so... no free lunch this time. Still, being able to do something like that might be kind of cool.

All of your lowest level non-container classes could simply have this Error method:
lparameter nError, cMethod, nLineNo
this.parent.Error( nError, cMethod, nLineNo, this )
So every object inherits the basic functionality to pass the error on to the object that contains it.

Then all of your lowest level container classes (any class with an AddObject() method) can have this Error method:
lparameter nError, cMethod, nLineNo, oError

if ( pcount() > 3 )
   * an error occurred in one of my child objects...
else
   * an error occurred within myself...
endif
But you start having more duplicated code, ie the same error method in all of your lowest level container classes. That's why I routed the Error to a UDF, then I can in one place handle the delegation either to the .parent or just pass it off to some global oErrorHandler. Since I defensively code around potential "foreseeable errors", like File Not Found etc, whenever an Error occurs it's usually of a fatal variety so the app should just terminate.

Have you read the article over at Stonefield.com?
df (was a 10 time MVP)

df FoxPro website
FoxPro Wiki site online, editable knowledgebase
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform