>Mike
>
>>If one puts closely related classes into the single distribution unit.
>
>Which is what I consider the optimal design.
>
>>>The design of the packaging of classes is nearly as important as the class designs themselves.
>>
>>I'm not sure about that.
>
>I am sure of it. And it seemed to me a lot of your argument was based on poorly chosen classlib packaging.

It's simply my opinion that there are rarely any well chosen classlib packaging styles.

>
>>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.
>
>I'm not sure what you mean by compound class here. A vcx/vct does store everything about a single class. It only stores instances of other classes dropped into it for designtime containership. It may or may not store: 1) association related classes this.oX = createobject(...) and 2) aggregation related classes this.AddObject(...)

I meant a class with other instances dropped into it so that it becomes a new class.

>
>>However, one is left with the possibility of storing UNRELATED classes and that is too often done. That is the problem.
>
>My point entirely, good classlib packaging is really required for good overall design and reusability.
>
>Mike, the bottom line for me is that the best classlib packaging lies in the middle of this spectrum:
>
>

>1 class per classlib ... All classes in 1 classlib
>

>
>You aren't ever going to convince me that your architecture at the left end of that spectrum is best. And I'm probably not ever going to convince you a mid-spectrum packaging is best. I was posting in this thread to perhaps steer others into the green light and away from the red and violet light. *s*

FoxPro itself may be seen as being on either end of the spectrum. It is either a single package of commands and functions or a set of one-class-per-classlib packages.

A real world example was just done to me. We have to produce a list of visits and show the distance between each visit. We compute distances between two addresses using mapquest.

I created a single function that would take two addresses and return the distance from mapquest (calculate_distance_between_two_addresses_with_mapquest) I didn't think about it before, but I should have made a mapquest wrapper. My single function should be two functions! Why? Because both mapquest-wrapper and calculate-distance-between-two-addresses would be encapsulated!

The second address column (address2) contains variations like this...

TORONTO, ON
TORONTO ONTARIO
TORONTO, ONTARIO

We will need a piece of code to break that address2 string apart break-apart-address2. Well... Guess what! There is a conversion routine available. It was written as a single massive piece of code by a third co-worker. It probably has a working break-apart-address2 bit of code. It is not encapsulation to store break-apart-address2 in the massive conversion routine. Break-apart-address2 is like a spark plug. Unfortunately break-apart-address2 is not only welded into the engine-block-like conversion routine, it never existed as a separate thing to begin with!

In any case, I emailed calculate_distance_with_mapquest to the second co-worker. Never mind that we have no facility for collaborative programming. He took my code - which was designed to be used like a spark plug, and WELDED it into a single .PRG along with his own custom-made break-apart-address2 routine AND the code to query the table. That query ends up calling both get_distance_between_two_addresses_from_mapquest and break-apart-address2.

Honestly it would take ZERO extra time to have made one piece of code to do the query and call my get-distance-between-two-addresses_from_mapquest and the third programmer's break-apart-address2 routine.

I had already made one of the pieces, the third co-worker had already made break-apart-address2. All the second co-worker had to do was write a query and call the two existing functions.

The end result is a single piece of code because no thought went into the packaging.

I don't know why it is done that way, but it is clearly inefficient. It is hard enough to know what the routines are called without having to also remember where they are filed, especially since none of us use the same filing system.

An arbitrary packaging is worse than none. A logical packaging is best. In the absence of these, no packaging works well.