Hi Jp...

I guess the first question is what type of classes are we talking about here - UI classes, or biz logic/utility classes, or what I sometimes like to call code-centric classes. Believe it or not, and Steve Black got me on this kick, I use PRG's for all non-UI centric classes. Because it is code-centric, inheritance really does not buy an awful lot. Whether you decide to go this way, or use the visual designer is not a big deal. However, you did mention something about creating a subclassing them. Simply put, if you don't need a layer in your class hierarchy, avoid it like the plauge. For your code centric classes, I would bet at most times, you instance them more than you actually subclass and then instance them.

As far as your UI-centric classes go, and the place where inheritance is most used, I would be very careful about falling in the inheritance trap accross your applications. For example, lets say you change something in one of your base classes. The next time you have to recompile any of your apps, you will need to test things throughouly to make sure you did'nt break things. This is especially true if you start modifyng the interface.

Like Nancy, I tend to group things in units of work. For an application, I might have a customer class library. Everything associated with a customer would be in that library. I might also have an orders class library, a reports class library, and so on. For base classes I have, I actually copy those class libraries to an application specific directory, and go from there. If, in those rare cases I do something that all apps could take advantage of, I will go ahead and make the change accross the board manually if necessary. Believe me, this is far better than ceding control to the inheritance monster. And lets face it, rarely will you have a need to take advantage of inter-application inheritance. Yes, you will take advantage of default behaviors in your classes. In these cases, you are merely creating instances of those classes, you are not subclassing them.

That said, here is a suggestion:

1. Group you base classes in categories that logically go together. Units or description of tasks is a good metaphor. A baseclass library that contains a subclass of each VFP control, a data class for special data behaviors, a utilities class for special network, printing operations, etc.

2. When you create an app, make a copy of your base classes for each app. People will debate me on this, and I am more than ready<g>. The fact is, if the classes are mature, they wont change that much. And, if you do things right, all you will have to do is recopy the base class libraries to you various app directories. This scenario also addresses the multi-developer/source code control gotchas.

3. For code-centric classes, try using PRG's. They are alot easier to manage than code in VCX's. And, in these cases, you really don't take advantage of inheritance all that much anyway.

Lastly, performance will be the least of your problems. Management of your classes is the biggest issue...

Good luck..


>I have collected quite a few classes. I was thinking of subclassing them all into a large class file in a shared directory in my development environment (as a sort of component repository). Then I would subclass just the classes I need for a specific application into a class that lives in a specific application directory. Does this make sense? Or should I split all my class files into some type of grouping. I guess my main question is: when you build an app that includes large class files containin classes that are not used, is there a performane penalty?