Hi David

>Most UML design tools have a strong concept of "packaging". It allows you to aggregate closely related classes into a single distribution unit. It makes great sense.

If one puts closely related classes into the single distribution unit.

>
>>An scx file is a natural and physical collection of things contained in that screen. A vcx for a compound object is also a physical collection of things contained in that object.
>
>In VFP the scx/sct is the packaging for all of the items in a single form. It makes great sense.
>
>>I object ;) to a vcx that contains unrelated things. I agree that there must be a class library, but it is often being used improperly, IMO. For example, putting all date calculation objects into the same vcx as the business objects makes no sense.
>
>The design of the packaging of classes is nearly as important as the class designs themselves.
>

I'm not sure about that.

>In VFP the vcx/vct is the packaging for closely related classes. It makes great sense.
>

The statement that an scx/sct is the packaging for all items in a single form is different from the statement that a vcx/vct is the packaging for closely related classes. I believe it would be better to have the vcx/vct be the packaging for all items in a single class, even if it is a compound class.

>>Before you arbitrarily group things together, I strongly advise you not group them at all.
>
>That's a rather anarchistic statement. *g*
>
>>For that matter, people are also doing things like putting a weekdays function into a payroll screen. Would you instantiate the payroll screen just to get that weekdays function? The weekdays function is not dependant on the payroll screen. Opting to keep the weekdays function outside of the payroll screen leaves that code available for every possible other purpose.
>
>Those people just need to do a better job in the design of their packaging.
>

However, one is left with the possibility of storing UNRELATED classes and that is too often done. That is the problem.

>>If you put all baseclasses in a single vcx, those classes are all automatically included in your exe. I would put all baseclasses one per vcx, except that I use MaxFrame. Things I subclass from it do go in one class per vcx. It is very liberating! I always remember the class I want and never have to remember where it's hidden.
>
>Yeah but in order to use ClassX of subsystemY you need to include ClassX.vcx and then you have to know (and include) all the other classlibs for the classes tha ClassX needs to operate correctly.
>
>Me, I'd rather just put SubSystemY.vcx in my project and be done with it.

The project manager looks after that for you. It is only important that you be able to instantiate ClassX.

If you need a gear like the one in the steering column, you must have access to the gear class, not the steering column subsystem. The gear class must be encapsulated unto itself before it can be used as part of the steering column subsystem. That way it can also be available for alternate purposes. Physically there would then be two instances of the gear class. At design time, there is only supposed to be one copy of the gear blueprint.