2.2 Components Should not Be White Boxes

The opposite of a true black box would be a white box , which reveals all details (Fig. 4). With a white box, all information to select a component and connect it to a given environment is available. The deployer of a white-box component can gain arbitrarily detailed knowledge about the component's internals. This knowledge can be used to decide the components applicability in a specific situation, but it can also be used when creating a context for it. If the implementation is the only available interface description, the usage of that complete information cannot be restricted in any sensible way.

  

Figure 4: White-box component

Why should such a restriction be necessary? To answer this question, we need to reconsider why we are interested in components at all. One reason may be to use the same snippets of program text over and over again. Indeed, if this is the only goal white boxes do the job. For an industrial style of component usage, however, this is not satisfying. There, components should reduce the complexity of larger systems and they should help to reduce the product's cost. The former requires that a component can be deployed without understanding the full complexity of its implementation, whereas the latter requires, besides others, that components can be selected from a free market and that they can be replaced individually, for instance to adapt to new requirements or to upgrade to new technology.

For both problems, abstraction from the implementation is the solution. Hiding away the details allows the reader to understand the essentials faster. A specification saying in one line that some data is sorted is much faster to grasp than the full implementation of, say, Insertionsort. Reconsidering the observer pattern, the black-box specification given in Fig. 3 is much shorter and simpler to understand than its white-box counterpart, the implementation, which e.g., uses text pieces.

Also, details that are not known by the deployer can be changed later without requiring the deploying system to be changed. For example, it may become interesting to replace the aforementioned implementation using Insertionsort by one based on Heapsort. If the full implementation would be made public before, some client may depend on the fact that elements with equal keys are not reordered. If this observation may be used by clients, Heapsort would not be a valid implementation. Thus, excluding the detail how elements with equal keys are treated from the specification results in higher flexibility.

This flexibility allows system composers to select from a set of different but alike implementations or to replace individual components later, for instance, for incremental upgrades.

In a nutshell, the problem with white-box components is that their deployers cannot know which of the provided information they may use without endangering later substitutability. Of course, such a substitution can always be done by reconsidering the entire system, that is, the new component together with the entire particular context. This could become a complicated task, however. It may become entirely impossible in a context that is created only very late, for example, by the user of a network computer [Szy96]. Additionally, by distributing source code the developer cannot protect the implementation know-how.