All three are dependent on an understanding of the domain involved. Domain analysis is the process of understanding a domain and writing down information about it in a somewhat formal way. Certain reuse design decisions will depend on the domain involved.
Reuse design principles will also be dependent on the type of the reusable object. Test cases, C functions, and Ada packages are all potentially reusable objects, but some of the methods for making them reusable will obviously be specific to their type. Object granularity, which is also a design discriminator, is subsumed by type.
Another factor that will affect reuse design is the environment the parts are used in. The way the parts are designed for reuse will be based on assumptions about the environment that they'll be used in. A good example of this is the Unix shell. In designing a shell tool one relies on the standardized byte stream interface. If this interface didn't exist, the part would have to be designed differently.
Thus, one might use the following example faceted scheme to classify reuse design principles.
| Domain | Type | Environment |
| database | function | Unix |
| statistics | package | C |
| test case | Fortran | |
| requirement |
Reuse is one of many design goals and must be traded off with some others. Reusability is usually inversely related to such design goals as efficiency of size and execution. Both Doug Lea and Mike Vilot have told me that simultaneously achieving reusability and execution efficiency in their libraries is necessary and difficult, but doable.
Several researchers [5], [4], [1], [6], have formulated a general model of design for reuse – the 3C's (concept, content, context) model. This model provides good insights into the reuse design problem, but does not provide detailed design guidance for specific LCO's. I'm not clear on how much this model overlaps with the scheme I'm proposing. I would like to discuss this point at the workshop.