Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Is one concrete Class per Class Lib a poor/good idea?
Message
De
14/07/2004 16:58:57
Mike Yearwood
Toronto, Ontario, Canada
 
 
À
14/07/2004 15:57:57
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Classes - VCX
Divers
Thread ID:
00916585
Message ID:
00924391
Vues:
54
Good to hear! I certainly don't think the classlibs and procedure libraries are a good organization tool. What I've done is break things down, making them atomic and always looking to make useful components, even the parts of components can be useful. I do get to use them in other projects.

>Hi Mike,
>I just wanted to comment on your 'lots of little files' concept. I like it, and wish I had used it a bit more. (It's a pain to change too much now.) I have used the concept with PRGs in the past, but not as extensively on VCXs.
>Just as an example, I work regularly with about 5 applications. Each one has about 43 VCXs, holding about 700 classes. There are over 150 prg files. Since we are involved in the same application domain in each of these applications, they almost all use most of the same files. The only difference between each application is metadata and lots of subclasses that change the behavior of the base classes. I tend to put all the app specific subclass code in two files: a prg and vcx. That works fine. However, lately I've created more and more base classes that hold only one class or perhap more, but ones that are all to be used together. So when it comes time to build an EXE, I only get the code I need. As I say, I wish I had done that even more.
>
>
>
>>>>Core may be the wrong word. I'm referring to functions that are atomic, like ISARRAY. It doesn't really belong anywhere, because it could be used in so many places.
>>>
>>>Theoretically I think you're right. However practically it seems more of a hassle as you'll end up with many, many prgs in your project cluttering up your PM (given the fact we cannot classify functions and classes in the PM). Let's be honest, if you were to design a prg with the most common atomic functions in there how many KB will that take?
>>
>>Size is irrelevant, so you can't use that as an argument. I'm more concerned with the difficulty of learning which PRG holds which functions. You say I'm cluttering up the PM with PRGS and I say you're cluttering up a PRG with procedures and functions. We're continuing to disagree about how they are organized. So let's get rid of the problem. We need a better way to categorize components while working, and a way for the project manager to have all the components it needs.
>>
>>>>I don't think we should just dream. We can make it happen. That is your signature after all.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform