It is impossible to hide all implementation issues behind a module interface because not all of them are details. Instead, some involve crucial strategy issues that inevitably bias the performance of the resulting implementation. We call these issues strategy dilemmas, because they involve a choice about how to implement a higher-level functionality in terms of a lower level one. Strategy dilemmas can be broken down into resource allocation dilemmas, where the implementor has to decide how much of a shared resource to allocate to each client, and mapping dilemmas, where the implementor has to decide how to map the functionality they are implementing onto the lower-level functionality.We call decisions by module implementors about how to resolve strategy dilemmas strategy decisions. When a particular client of a module performs poorly because the implementation embodies an innappropriate strategy decision, we call it a strategy conflict.
Despite black-box abstraction's appealing goal that a module should present a simple interface that exposes only functionality, there's a great deal more to a module than is acknowledged by that interface.
Our claim is that module implementations must somehow be opened up to allow clients control over these issues as well. We call this the need for open implementations.
![]() |
Return to the Open Implementation
Site Guide Return to the Open Implementation Home Page |