Hi Srdjan
[snip]
>>
>>As to grouping multiple classes into one vcx - I'm with Mike here. The only reason I'd have two of them together would be that I know for sure that one would be used nowhere else but in the other one. The only exception is the framework itself, which sits in one large vcx, all 30 or so classes. Everything else is in a separate vcx or prg. Careful naming is needed, though, because there's no other way to keep things grouped in ProjectManager.
>
>Are we are talking about regular GUI building classes
>of business objects ?
>I just cannot imagine (aldough I will try to see :)) having
>to switch library everytime I want to add something to my form...
>Or having to issue arrays of 'set classlib to ... additive' statements
>when you are adding objects on the fly.
>
When dragging from the project manager, I open the classlibs I will be using and drag from those to the form. I really wish there was a class file in addition to a class library file. Then I would just drag the classes I want without having to expand the classlibs at all.
>If I remeber correctly, at the VFP beginnings, everybody was advicing (I and perhaps many other people folowed it) , having all VFP baseclasses subclassed in one library and then subclassing it from there, for further addition of functionality.
>Over period of years everybody perhaps built their controls and other common libraries according to their standards, needs, frameworks etc.
>
>To sameone who did this, concept discussed in this thread really does not sound apealing ...
>
It is advisable to subclass the baseclasses. Putting them all in one classlib is nothing more than coincidental cohesion.
http://en.wikipedia.org/wiki/Cohesion>For bussiness objects especially if they are huge, maybe it could be usefull. But I wld not know as I am building those (my version of it) in PRGs usualy. And even there they are bunched up together in one prg per database / project.
All the business objects for a single system are in one PRG? "Functional cohesion is when parts of a module are grouped because they all contribute to a single well-defined task of the module (a perfect module)."
Each business object may perform a single well-defined task. The collection of them does not do a single well-defined task. The collection itself does nothing in the system.
