>I can see from your reply that you have encountered these issues before and worked out solutions to your satisfaction. My situation is that I am converting a Foxpro DOS app to VFP. It deals with used car dealerships. When a car is sold there are any number of types of deals that can be worked out- these I will all subclass so that the individual code is easier to work with than the present jumble of cases and if statements that I have. This will allow me to easily create new classes of customers without in any way infringing on the behavior of present customer classes. On the other hand, once a customer is in the system the tracking of accounts receivable and the creation of reports again becomes very complicated. My idea is to have 1 set of classes to handle the sales end and another parallel set to handle the follow up activities. The only reason to split it up that I can see is just have smaller less complex classes. I already know what the behavior of the present classes will be,
>the problem is extracting it from the DOS code. Life is hell right now, but if I ever get this done I will have far fewer problems down the road.

Someone may find what's the name of this design pattern, but I've found it very convenient to have a family of behavior classes, which are AddObject()ed to a general member (customer, in your case) class. Actually, the members are stored in tables, and one of the fields holds the behavior class name. When a member object is instantiated, it AddObject()s a behavior object into itself. Of course, all the classes in the family must have some common methods (is this what they call polymorphism?) so the member object doesn't have to know zilch about the behavior object's specifics.

In your case, it could apply as each customer object containing two behavior objects: sales object (i.e. belonging to a family of SaleType classes) and a followup object (from FollowType family of classes).

Maybe you may save some time with this, because this allows you to have separate classes for sale types and followup types, instead of having to have a separate customer class for each combination of them.