The Importance Of "Requires"

Classic interface definitions tend to only to focus on the "Provides" aspects. However, there is a growing movement in the architecture community to additional include a "Requires" aspect to interface definitions. A "Requires" specification usually contains contextual information necessary for a component to perform its responsibilities. The Dependency Injection movement introduces the capability to express these dependencies in a explicit manner.

In a paper "Integrating Independent Components with On-Demand Remodularisation" the authors write:

Support for bidirectional communication: Interfaces provide clients with a contract as what to expect from a server object that implements the interface. We say, they express the provided contract. In order to define generic components which are decoupled from their potential contexts of use, expressing expectations that a server might have on potential contexts of use is as important. We use the term expected contract to denote these expectations. What is needed is support for a loose coupling of client and server, that is (a) decoupling them to facilitate reuse, while (b) enabling them to tightly communicate with each other as part of a whole.

In otherwords, a component model that does not explicit express its required context is implicitly coupled to its context. It's like the spaghetti and meat balls analogy. You can't pull out the meat ball (i.e. the object) without a lot of noodles clingling on to it.

The advance of Spring has finally put a spot light on the implicit coupling between a component and its context.