Black boxes

Bij de beschrijving van systemen worden onderdelen waarvan je aan de buitenkant niet kunt zien wat het van binnen doet black boxes genoemd.

Als het goed is heb je als gebruiker een handleiding voor het gebruik van de black box: wat je op de ingangen moet aanbieden en wat er dan op de uitgangen gebeurt.

Waarom zou je iets willen gebruiken waarvan je de interne werking niet kent ? Dat heeft vooral te maken met hergebruik van iets dat een ander al voor je heeft uitgezocht zodat je dat niet zelf nog eens hoeft te doen. In deze lessen gebruiken we black boxes niet zozeer als onderdelen waar we niet in KUNNEN kijken, maar vooral als onderdelen waar we niet in WILLEN kijken.

Iemand vroeg of je 'closed source software' ook als black box kunt zien. Dat kan misschien wel als het zo bedoeld is, maar het idee van closed source is vooral dat een ander niet mag weten hoe het intern werkt. Bij ontwerpen met black boxes is het doel dat een ander niet hoeft te weten hoe het werkt.

Subpatches (bv in MAX/MSP of PD) zijn wel een mooi voorbeeld van black boxes: die maak je om je project overzichtelijker te maken en je kunt er wel in kijken maar je kunt ze ook gebruiken zonder te weten wat zich intern afspeelt, als je de functie van de inlets en outlets maar kent.

Voordelen van black boxes

Ontwerpen met black boxes heeft een aantal voordelen:

• De gebruiker van een black box hoeft de interne werking niet te kennen maar alleen te weten hoe hij het moet gebruiken
• De maker van de black box mag altijd de interne implementatie veranderen mits de externe werking daardoor niet verandert
• Als je bij het ontwerpen van een groter systeem denkt in termen van samenwerkende black boxes dan ben je het systeem aan het opsplitsen in onderdelen die onafhankelijk van elkaar en zelfs door verschillende mensen ontwikkeld kunnen worden

Voorbeelden van een black box

• software-bibliotheek (library)
• Max-patch of PD-patch op lager niveau
• remote server
• externe classes