The above closure restrictions may be lifted either by choice or by necessity, resulting in a continuum of open composition strategies involving collaboration networks, resource sharing, and larger scale opportunities for reuse. And larger scale opportunities for disaster: aliasing, interference, and lack of independence and local verifiability. These must be dealt with via combinations of design rules (e.g., access control policies), organizing constructs (e.g. ``groups'', ``roles''), and worst-case implementation techniques (e.g., locking, atomic transactions). The presence of such dangers, along with the sheer difficulty of their diagnosis, prevention, and control can be a limiting factor in successful reuse of individual classes. However, semi-isolated networks in which these factors are known to be under control are often reusable as a group.
Moreover, by abstracting over the functionality of a system or subsystem of components, and only paying attention to their static and dynamic interrelations, one may use/reuse the resulting design architectures. Architectural reuse ranges from the everyday use of ``standard forms'' of static connections (e.g., simple linked lists), to the incorporation of design patterns that represent solutions to common structuring problems (e.g., model-view-controller designs), to the system-wide adoption of large-scale architectural frameworks (e.g., software bus, Linda tuple space).
Architectural reuse may or may not involve any actual code reuse. Some architectural elements may indeed be completely isolated from application-specific functionality. The isolation of elements into nodes and use of parameterized code to construct lists of such nodes represents a familiar example. Similarly, ``protocol objects'' such as multicast controllers may be reused in the construction of group broadcast designs without regard for the contents of multicast messages.
However, there may be at least an equal number of examples in which no code reuse is possible. For example, OO components assisting in the construction of many general graph structures seem little used, perhaps because of typical application-specificity of node and edge semantics. Instead, the general ideas are manually adapted to the situations at hand. It is not clear (and not worth debating) where to draw the line between this form of reuse and the application of ``general design knowledge''.