>Thank you for your replies. I would understand from this that if it is possible from a design and maintenance viewpoint it is better in terms of operational speed to create famlies of classes. In other words, if I have several types of customers (cash customers, financed in house customers, sweetheart deals with finance company customers etc) I could create one family of classes to handle the creation and saving of customers and another family to handle payments, accounts receivable etc. This would split the code up and allow faster loading and execution. I am obviously new to this and I just worry that I will go overboard and really slow down the app. Should I be concerned?

My rule of thumb is that code has to be loaded, and it's loaded only once. Therefore, for each object, VFP must load its class definition; if it's already there (because we already have an object of the same class in memory), it doesn't load it again. It must create an instance, which probably contains the non-default properties (.parent, .value, .left, .top etc).

Now if we create an object whose class is a subclass of what we have already loaded, its class definition must also be loaded, but it's probably shorter (as others upstream of this thread have already said), because it contains only the specifics added by subclassing, and the rest is just missing - it will be found in the parent class. Again, several objects of this class will have only an instance somewhere in memory, with just non-default properties; the rest is taken from the class definition; what's missing there, is taken from the parent class definition, ... going up to the base classes.

Come to think of it, it's very economical in terms of memory consumption. In your case, you'd be better off creating a general customer class, and subclass it for specific behaviors, or just have a financial class for the instance to use, and pass its name as the parameter when instantiating... like this:


loNewCustomer=CreateObject("Customer", "CashPayment")
loNewCustomer.money.PrintInvoice

Define Class customer as custom
TransType=""
Proc Init
lpara pcTransType
< parameter checking needed here >
this.addobject("money", pcTransType)
EndProc
enddefine

Define Class CashPayment as custom
Procedure PrintInvoice
< stuff some code here >
EndProc
enddef

You may have several classes like this CashPayment, and still have only one Customer class.