2.3 Components Should Be Grey Boxes

Black-box components providing too little information and white boxes revealing too much, we need to go for a middle ground, which we may call grey-box components. A grey box reveals parts of its internal workings, not just relations between input and output. The information can become as detailed as necessary where needed, for instance, to state under what conditions external components are called. In other places it may remain very abstract and simply state a condition that is established (Fig. 5).

  

Figure 5: Grey-box component

Taking up the observer pattern from Fig. 3 we give the corresponding grey-box specification in Fig. 6, which clearly states that the delete notifications are sent after the modification.

  

Figure 6: Grey-box specification of observer pattern

Revealing some internal information might also help the client programmer improve the performance of the complete system by taking advantage of the knowledge which call backs are made in what state. Kiczales argues that the abstraction and the resulting loss of control of performance-relevant details makes black boxes hard to reuse [Kic94]. He suggests a metaobject protocol for providing client control over the internal workings. Grey boxes might be a complimentary solution.

In summary, we can say that the main purpose of a specification is to make clear what a client can rely on, resp. what every implementation of that specification has to provide. For this, stating relations between input and output values is not always sufficient. Thus, we need a mechanism to express those parts of the implementation that are relevant to the client programmers in a way that does not fix any unnecessary details.