Blackboxes respect the information hiding principle: To use a black box, you only need to know its responsibility and its input and output interfaces. Additional details from its inner workings are (usually) not required.

This concealment provides a number of advantages:

• You can change or modify the inner workings, without users (clients, consumers) needing to adapt to those changes.
• You might refrain from documenting the whitebox of this building block. That can reduce the maintenance effort of your documentation.
• Eventually you reduce the level of details that some stakeholders have to consider or know.

In extreme cases you restrict the building block view to level-1 (see tip 5-3 (‘level-1 is your friend’)), the whitebox of the overall system - without detailling any of the top-level building blocks.

Information sometimes required

According to “blackbox-theory”, knowing the responsibility and interface of such a blockbox is sufficient. But in reality, sometimes additional properties of such a building-block are required - for example runtime- or deployment properties or other kinds of qualities.

Let’s consider a simple blackbox - the square-root function (short “sqrt”) has a very simple interface (“API”):

sqrt( number ) -> number

where number > 0.

For a sqrt-blackbox the following several other properties might be important:

• what precision does our sqrt-blackbox provide, how many digits will it deliver. (“Correctness”)
• are all users allowed to use sqrt, or is our sqrt restricted to specific users (“Authorization”)
• can our sqrt-function be called by many parallel users (“parallelism, multi-user-capability”)
• will usage of our sqrt-function cost money
• how fast will our function deliver its results (“performance efficiency”)

From the examples you see that several “Qualities” might be relevant for your blackboxes.