Module relationships

Understanding how one module relates to another helps determine how it reacts to changes in that module.

A single module can have the following types of relationships with another module:

• uses: module A uses module B if it invokes behavior of module B

• reacts to: module A reacts to module B if its behavior is triggered by an event in module B without module B knowing about module A

• customizes: module A customizes module B if it modifies the behavior of module B

• implements: module A implements module B if it implements some, not necessarily all, behavior that is defined in module B

• replaces: module A replaces module B if it provides its own version of the API exposed and implemented by module B

Relationship types and scenarios

A uses B, C customizes B

In a scenario where module A uses module B and module C customizes module B, the customizations in module C must not break the API of module B so that module A still functions properly in the face of these customizations.

A reacts to B, C customizes B

Similarly, in a case where module A reacts to module B and module C customizes module B, the customizations in module C must not interfere with the events in module B that module A depends on.

A and C customize B

If both module A and C customize module B, be careful about how these customizations are implemented so that you avoid conflicts (see below).

A replaces B

If module A replaces module B, it needs to be able to do so in such a way that other modules are not affected. That will mean not having direct hard dependencies on module B, but rather dependencies on a third module, module C, that both module A and B implement.