You may have heard of the idea of “Blackbox” development. Where is it? Can I open it? What does it contain? Is it that red rider BB gun I wanted from xmas all these years? NO! It is the idea of encapsulating or “hiding” implementation details about a software component. In today’s entry, we will cover what it means to be blackbox and how designing with this idea in mind can help you.. only in this issue of the Programming Underground!
The idea behind blackbox design is that you design a component, be it a function or subsystem, with the idea that no one is to see how it works. You write the component to do one thing and one thing only, but how it is done is irrelevant to those other components (or users) using it. You simply don’t care how the component is put together as long as it does its job and does it well. Why is this advantageous?
1) It causes it to be loosely coupled. Meaning that it doesn’t depend on other systems or components to function properly. It is self contained and thus highly interchangeable. You could essentially pick it up and drop it into another system and expect the same behavior without actually knowing how it is put together.
2) It simplifies testing in that all you have to do is watch the inputs to the component and compare the outputs to expected results until it is extremely reliable. You don’t have to trace it through the component, you just have to watch what it produces when given certain input. This idea makes it easy to incorporate into existing systems… if tested with some old or bad production data. You can stress test it and see if it breaks. It is a solid working unit.
3) It reduces complexity. If you are working on a more complex system and don’t want to handle the fuss of writing to that external file, you can drop in that blackbox file writing component, pass it the lines you want to write, and it does its job. You can then focus on other things like getting that stupid binary tree search algorithm to work! Damn you binary tree!
4) It allows you to build an archive of resources. If you design a blackbox item that is self containing and independent, you could store it away in a library of components that can later be used in other projects or even be sold. It can become an asset of your company and thus have value.
Some terminology that you may hear behind blackbox is “encapsulation” or “data hiding” which is idea of keeping variables and statements local to the component and unknown to any system, or user, that wants to use the component. These will be your private variables, private methods etc. By making everything local and hidden away (exposing only through public methods where you can keep track of how the internals members are changed) you create less dependency on foreign data and hence self sufficient. You may hear this in your classes as “decoupling” the component from other components.
Most of the time when you put in several blackbox items, they can only send messages to one another to communicate (using function calls for instance). Since none of them know the implementation of one another they can only know what your component tells them is available (through their interfaces… which is why interfaces are useful here). So if I know I have a file writing component in my project, and I know nothing about its inner workings, then all I have to work with is the publicly defined methods. I know that if I send it a filename and a string of text it will write that to the file.
How does blackbox development help you in your everyday projects? Well if you have an archive of blackbox components, you can shop and just drop into your new project, speeding up your development time and increasing the reliability of your projects. Since you know each part works well, all you have to do as a programmer is design the look and how each component will communicate (like calling each others methods).
Now the opposite of a blackbox is what? You probably guessed it, whitebox (sometimes referred to as glassbox or clearbox). If a blackbox hides its inner workings, the whitebox actually makes them available for inspection. Some companies will design whitebox components until they have been fully tested and inspected to work, then turn them into blackbox when it is time to save it away and put it into other projects. Usually open source companies will leave everything white box so that you can see how everything is put together and even modify it if you want.
And no, there is no greenbox, redbox, purplebox and plaidbox!
In conclusion, blackbox design can help you simplify your projects by providing you with well tested reusable components that you can just drop in and attach. This can speed up your development timelines, provide you with a library of resources, and develop more flexible software. The opposite of blackbox is whitebox and you may see this in open source software. However, you should always strive for blackbox development in your projects, especially if it is going to be commercial and you plan to sell it. You never know when you may need to rip out that great binary tree search algorithm and put it into another project. That way you don’t have to curse yourself out again for designing it wrong the first time.
